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oute maîtrise d'ouvrage, toute maîtrise d'œuvre, tout chef de projet infor- 

matique aimerait que le déroulement d'un projet, ou d’un ensemble de 
projets interdépendants, visant à adapter les systèmes informatisés de l’entre- 
prise, se fasse dans les délais les plus courts possibles sans rien sacrifier à la 
qualité. De plus, tous les acteurs des divers métiers, ainsi que le management en 
général, souhaitent que des modifications au projet initial puissent être prises en 
compte de façon quasi continue, et ce jusqu'à l'extrême limite du possible, sans 
bien sûr désorganiser le projet ni mettre en péril les livraisons en cours. 


C'est cette capacité que l’on appelle agilité, ou adaptabilité, au contexte 
socioéconomique, par analogie avec ce qu'en gestion de production on a 
appelé ateliers flexibles. Dans le milieu de la production, on est passé depuis 
quelques décennies d'une stratégie fondée sur l'offre à une stratégie fondée 
sur la demande du client final : il faut répondre à la demande, le plus vite pos- 
sible. C'est la demande qui pilote la fabrication. 


Dans le monde de l'informatique, la métaphore manufacturière trouve rapi- 
dement ses limites. Une chaîne de montage industrielle est relativement 
stable, vu les investissements nécessaires à son installation, alors que l'infor- 
matique est l’objet de modifications continuelles. On demande beaucoup plus 
à la partie programmatique qu'à la partie matérielle du procédé de fabrication 
car c'est là que réside la spécificité, et la grandeur, de la technologie 
informatique : on peut programmer, changer les processus, sans modifier le 
matériel ; c'est un avantage compétitif décisif pour celui qui sait en tirer partie. 
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Glossaire 
ACL Article de Configuration Logiciel 
AË Architecture d'entreprise ; englobe et généralise 


le concept d'urbanisation du SI à l'ensemble 
de l'entreprise 


AP Arbre Produit - PBS, Product breakdown 
structure (issu de l'architecture) ; voir OT 


AO Assurance Qualité ; en anglais, OA 
CDV Cycle de vie 
CDVL CDV Logiciel ; en anglais : SDLC, Software 
Development Life Cycle 
CDVS CDV Système 


COCOMO COnstructive COst MOdel - Modèle d'estimation 
en COPD élaboré par B. Boehm ; cf. Software 
engineering economics et Software cost 
estimation with COCOMO II 


COTS Component off the shelf- Produit/progiciel 
sur étagère 


COFD Coût, Qualité, Fonctionnalité, Durée 
(de réalisation) 
DG Direction Générale 
DSI Direction des Systèmes d'Information 
FCS First Customer Shipment - Date de 1°" livraison 


d'un produit chez un client 


FURPSE Fonctionnalité, Usabilité (facilité d'emploi), 
Fiabilité (reliability)}, Performance, Maintenabilité 
(serviceability), Évolutivité - Classification 
des caractéristiques qualité selon la norme 


ISO/CEI 9126 
IS Ingénierie Système ; en anglais : 

System Engineering 

ITIL Information Technology Integrated Library 

IVVT Intégration et VVT 

LS/KLS Ligne Source - Unité de comptage pour la taille 

des programmes ; en K{kilo)LS dans COCOMO 

MCO Maintien en Condition Opérationnelle ; 


activité de maintenance au sens large 


MOA Maître d'Ouvrage ; en anglais, the process owner 
(cf. I. Jacobson). Se dit également de 
l'organisation en charge de la maîtrise d'ouvrage 
(en anglais, Project Office) 


MOE Maître d'œuvre ; organisation en charge 
de la réalisation, généralement au sein de la DSI 
OMG Object Management Group ; voir le site 
www.omg.org 
OT Organigramme des tâches - WBS, Work 


breakdown structure ; voir AP 


PESTEL Politique, économique, Social, Technologique, 
Environnement, Légal - Classification 

des facteurs de l'écosystème projet 
(terminologie INCOSE) 


PF Point de Fonction — Unité de mesure de la taille 
fonctionnelle d'une application. Il existe 

des tables de correspondance entre PF et LS, 
par type de langage de programmation 


ROI Return Of Investment - Retour 
sur investissement 


SI Système d'information ; au sens large, incluant 
tous les acteurs humains + équipements 


1. Problématique et enjeux 


Pour comprendre la problématique et les enjeux dont cet article 
est la thématique, examinons les problèmes auxquels un chef de 
projet doit faire face durant le déroulement de son projet, mais 
aussi avant et après le projet. 


Tout projet, quel qu'il soit, et c'est encore plus vrai des projets 
où l'informatique est un enjeu, est une suite de problèmes liés à 
des situations particulières, problèmes que le chef de projet doit 
résoudre, au fur et à mesure de l'avancement du projet. Il en 
résulte une courbe de charge nominale qui a toujours la même 
allure, avec trois phases distinctes : 1) la montée en charge avec la 
constitution de l'équipe projet qui correspond à la phase de 
conception, 2) le régime de croisière qui correspond à la phase de 
développement proprement dite, 3) la terminaison avec l'intégra- 
tion et la mise en exploitation qui clôt le projet et prépare le pas- 
sage en maintenance qui durera autant que le système livré sera 
utilisé. Les pentes p1 et p2, sur la figure 1, représentent la montée 
en charge de l'équipe jusqu'à son palier. Dans le cas p2, il faut 
embaucher et intégrer plus vite le personnel à l'équipe, car l'effet 
de la compression « du délai augmente mécaniquement la pente 
de la courbe de charge initiale. 


Cela peut se représenter par la figure 1. 


L'impact de la compression des délais a fait l'objet de 
nombreuses études, notamment au moyen du modèle d'estima- 
tion COCOMO qui est le meilleur modèle pour appréhender les 
phénomènes liés à la dynamique projet. 


Nota : COCOMO : Constructive Cost Model. Voir nos ouvrages, Productivité des pro- 
grammeurs et Coûts et durée des projets informatiques, chez Hermès-Lavoisier, dans 
lesquels toutes les références utiles sont fournies. La version la plus récente du modèle 
est présentée dans l'ouvrage Software cost estimation with COCOMO II, Prentice Hall, 
2000. 


Le fait de comprimer les délais d'un coefficient & pour améliorer 
la réactivité de l'organisation des projets, engendre deux phéno- 
mènes aux effets opposés : 

-comprimer le délai diminue le temps d'exposition aux 
demandes nouvelles ou aux modifications de l'environnement du 
projet ; il en résulte moins de problèmes à résoudre en prove- 
nance de l’environnement, moins de risque de « turnover », etc. ; 


À Effectif 


N/o. : à 
Augmentation des effectifs due 


à la compression des délais 
Optimisation 


des livraisons sur le délai, 
et non sur le coût 


e— Optimisation globale 
COFD 


—#——— Compression & 


Délai 
D 
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Figure 1 - Résolution des problèmes dans un cycle projet 
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— pour compenser la réduction du délai à coût constant, il faut 
augmenter les effectifs ; il en résulte plus de travail en parallèle et 
plus de problèmes internes du fait de l'augmentation des interac- 
tions entre les personnes de l'équipe projet. Le travail à effectuer 
doit être découpé en grains plus fins, ce qui augmente l'effort de 
conception. Pour ne pas allonger le délai de conception, l'archi- 
tecte doit être plus expérimenté. 


Le chef de projet, et le maître d'ouvrage du projet, sont face à un 
dilemme. 


— Pour produire plus vite, il faut plus de monde sur le projet, ou 
réutiliser ce qui a été fait dans d'autres projets, ou récupérer du 
code sur étagère, etc. Il faut une capacité renforcée à 
communiquer tant à l'intérieur de l’entreprise qu'à l'extérieur ; de 
plus, une excellente connaissance du milieu est indispensable 
pour exploiter au mieux le savoir-faire de l’entreprise. Cela requiert 
tout à la fois plus de compétence et plus d'expérience de la part 
des acteurs qui doivent être polyvalents. 

- Mettre plus de monde sur un projet, pour en diminuer le délai, 
revient à dire que le coût de mise à disposition d'une nouvelle res- 
source est compensé par une productivité accrue, ce qui contredit 
une des célèbres « lois » de Brooks [1] : « Ajouter des ressources à 
un projet en retard, le retardera plus encore ». Pour éviter ce syn- 
drome bien connu, il faut s'assurer d'une part que le projet n'est 
pas en retard, mais que, d'autre part, il a une capacité d'absorption 
de nouveaux acteurs, jusqu'à une certaine limite à ne jamais fran- 
chir. Cette capacité est liée à la modularité de l'architecture, qui 
elle-même dépend de l'expérience de l'architecte. 


Pour que des entrants sur un projet soient immédiatement opé- 
rationnels, il est indispensable que le « milieu » du projet, l'éco- 
système de l'entreprise, soit porteur de standards, communs à 
tous pour faciliter la communication et surmonter les obstacles 
culturels. Les contributeurs potentiels du projet doivent être asso- 
ciés le plus tôt possible à l'architecture du système de façon à être 
immédiatement opérationnels ; l'information doit être facilement 
accessible. 


Les phénomènes de communications dépendent du nombre 
d'acteurs, de la rigueur des échanges et de leur expérience : plus 
les acteurs sont nombreux et inexpérimentés, plus l'entropie aug- 
mente, plus les risques de désaccords, de conflits, d’ambiguïté 
sont élevés. Il est souhaitable de minimiser le nombre des acteurs 
et de choisir le personnel le plus qualifié, compte tenu de la nature 
du projet. 


Dans cet article, nous allons examiner les conditions nécessaires 
d'une bonne dynamique des projets, sous différents angles : tech- 
nologique, méthodologique, architectural, intégration, organisa- 
tionnel et humain. Cela permettra d'évaluer avec une relative 


où chacun doit pouvoir travailler en confiance avec les autres, 
dans une saine émulation. L'équipe projet doit avoir le culte de la 
qualité et la fierté du travail bien fait. C'est à ce prix que le défi de 
la compétitivité sera relevé. 


Nota : c'est une terminologie économique. En anglais, on parle de « user agent» ou 
simplement « agent ». 


2. Facteurs d'échec 
dans les projets 
informatiques 


Dans les années 1990, un rapport célèbre, « The Chaos Report », 
publié par le Standish Group, établissait que le taux d'échecs 
observé aux États-Unis était de l'ordre de 30 à 40 % selon la taille 
des entreprises, qu'environ 50 % des projets nécessitaient de très 
sérieuses ablations pour voir le jour, avec en prime une augmenta- 
tion des coûts et des délais, et que seulement 10 à 15 % se termi- 
naient conformément aux objectifs initiaux. Ces statistiques n'ont 
jamais fait l'objet du moindre démenti pour ce qui concerne 
l'Europe, et l'on peut dire sans crainte d'être contredit que tout le 
monde est logé à la même enseigne : performance particulière- 
ment médiocre, quand bien même, toujours selon le Standish 
Group [2], la situation s’est un peu améliorée depuis. 


La « Top ten list » des facteurs de succès FS est, dans l’ordre, la 
suivante : 


—FS1: support actif du management et des décideurs de 
l'entreprise ; 

— FS2 : implication forte des usagers (les besoins et exigences 
sont bien définis et validés avec les usagers réels du futur 
système) ; 

— FS3 : chef de projet expérimenté ; 

— FS4 : objectifs et finalité métier du projet clairs (ÿ compris ce 
qu'il ne faut surtout pas y mettre) ; 

—FS5: minimisation du périmètre du projet (principe de 
sobriété : ne surtout pas encombrer le projet avec des objectifs 
superflus) ; 

— FS6 : infrastructure informatique stable et standardisée (mini- 
mise le risque à l'intégration) ; 

— FS7 : identification d'un noyau dur d'exigences autour des- 
quelles pourra s'organiser l'ensemble du développement et les 
premières livraisons ; 

— FS8 : existence d'une méthodologie de management de projet 
formalisée, partagée par tous les acteurs du projet qui facilite la 
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es méthodes dites « agiles », qui apparaissent sous cette appellation dans 

les années 2000 ont cependant une histoire un peu plus ancienne. Comme 
souvent, et malheureusement, en informatique on change la terminologie à 
défaut de changer de concepts. Le seul résultat certain de cette pratique déplo- 
rable est la confusion dans les esprits, en particulier celui des décideurs qui ont 
fini par perdre toute confiance dans ce que leur racontent leur DSlI et/ou leurs 
experts informatiques. Le scepticisme et la défiance règne. 


À la fin des années 1980, James Martin, auteur prolixe, a publié en trois 
volumes, chez Prentice Hall, son Information Engineering, qui a donné nais- 
sance, quelques années plus tard au RAD (Rapid Application Development) 
vite connu sous l'appellation « Quick and Dirty » et complètement décrédibilisé 
suite aux mauvaises pratiques qu'il a engendré. Il y avait beaucoup de bonnes 
choses dans l'Information Engineering, mais comme on peut s’en souvenir, 
c'est l’époque de la rupture technologique, avec le développement fulgurant 
des architectures distribuées, du client-serveur avec ses différentes variantes 
(client lourd, client semi-lourd, client léger, etc.). Les langages « anciens » 
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comme Cobol, même rénovés avec les générateurs d'applications et autres 
LaG qui fleurissent vers la fin des années 1980, n'intéressent plus grand 
monde (quand bien même il reste encore des milliards de lignes de codes en 
Cobol dans les banques, les assurances, dans les administrations...). La mode 
est désormais aux langages objets (C++, Java) et aux méthodes de conception 
orientées objets qui, dans les années 1990, donneront naissance au langage 
UML. On est encore dans l’euphorie de l'intelligence artificielle, dont le battage 
médiatique a réussi à faire croire à de nombreux décideurs que l’on va pouvoir 
mécaniser la fabrication des programmes (en se débarrassant des program- 
meurs, ces gêneurs qui font des erreurs et qui sont incapables de s'exprimer 
dans un langage compréhensible de tous) et enfin, connaître le meilleur des 
mondes informatiques où l'erreur a disparu comme par magie. Le réveil, qui 
prend les allures d’un crash, sera particulièrement brutal (cf. le rapport Chaos 
du Standish Group [Doc. H 3 200]). 


C'est également la période de tous les excès issus d'une démarche qualité 
mal comprise, qui va vite se transformer en bureaucratie, dont l'objectif est de 
satisfaire à des normes souvent ineptes (la norme du DOD 2167, tristement 
célèbre, est encore dans les mémoires de certains), inventées par des 
«experts » n'ayant jamais réalisé un système de leur vie. Comme on le sait, 
l'échec sera au rendez-vous, avec en plus un discrédit général sur la qualité 
dont on n'ose même plus prononcer le nom dans les entreprises qui se veulent 
sérieuses et informées. 


Il faut également signaler le cycle de développement dit « en spirale » popula- 
risé par B. Boehm dans son article de la revue IEEE Computer, vol. 21, n° 5, mai 
1988, À spiral model of software development and enhancement. Comme tout 
ce qu'a publié B. Boehm, c’est intelligent et profond, fondé sur la vraie expé- 
rience de l’auteur en matière de système logiciel. L'idée de Boehm est de coupler 
le processus de développement classique « en cascade » avec une gestion de 
risque qui donne des critères de convergence permettant de réaliser le système 
attendu par les parties prenantes. C'est une façon élégante de gérer les rétroac- 
tions sur une base réellement objective : quel décideur sensé pourrait refuser de 
prendre en compte les risques identifiés qui mettraient le projet en échec ? 


Sur toute cette période, le lecteur intéressé peut consulter le recueil de 
textes, sélectionnés par D. Reïifer, Software management, publié par l'IÈEE en 
1993, qui donne une bonne photo des problématiques de l’époque. 


En fait, rien de vraiment nouveau dans la démarche agile, si ce n’est, comme 
on dit au football, une remise de la balle au centre. 


1. Textes fondateurs 
des méthodes agiles 


1.1 Pourquoi les méthodes agiles ? 


On peut s'interroger sur l'apparition d'un phénomène socio- 
culturel comme les méthodes agiles et « l'eXtreme Programming » 
dans les années 2000. Constatons la concomitance de plusieurs 
phénomènes, sans qu'il Y ait un quelconque lien causal entre eux, 
mais qui tous amènent un surcroît de complexité dans les systèmes 
informatiques. 


La taille des applications n’a fait que croître tout au long de ces 20 
dernières années. L'arrivée des PC sur le marché, à des prix défiant 
toute concurrence, a permis de diffuser la technologie informatique 
dans tous les corps de métiers. La majorité des usagers de l'infor- 
matique ne connaît rien à la technologie sous-jacente, mais pour 
rendre cette technologie acceptable, il a fallu développer des IHM 
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dont le volume se chiffre aujourd'hui en centaines de milliers d'ins- 
tructions. Ces logiciels IHM, inexistants jusqu'au milieu des années 
1980, sont très complexes car événementiels et dépendants du 
niveau culturel et de la maturité de l'usager: ils doivent être 
conviviaux et respecter les règles de l'ergonomie (en fait, c'est la 
seule vraie bonne retombée de l'IA). Il y a une véritable co-évolution 
du couple usager/IHM, au sens biologique du terme. 


La frénésie technologique a complètement déstabilisé les inter- 
faces traditionnelles permettant de mettre les applications à l'abri 
des innovations et des évolutions des plates-formes. Aujourd'hui, 
tout est instable, ce qui fait que si le programmeur ne sait pas 
organiser son programme pour le protéger des évolutions des 
plates-formes, il aura la durée de vie de la plate-forme, ce qui est 
inacceptable d'un point de vue économique. Si le prix du hardware 
s'est effondré, celui du software n'a fait que croître. L'assurance 
qualité, les modèles de maturité des années 1980 avaient comme 
raison d'être d'optimiser des processus eux-mêmes relativement 
stabilisés, et évidemment pas de résoudre les problèmes à la place 
des concepteurs ; cela aussi a été oublié, et l’on a fait jouer à tous 
ces modèles un rôle que, par définition, ils ne pouvaient pas tenir. 
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Il faut ne rien avoir compris au logiciel pour ramener la qualité du 
logiciel d'une part a) à l'épaisseur de la documentation ou aux 
plans types des documents, et d'autre part b) à des choix d'outils 
que certains Vendeurs présentaient comme tellement 
« intelligents » qu'ils dispensaient leurs utilisateurs de réfléchir ; le 
slogan était : « l'outil fera tout cela à votre place ». 


Les architectures logicielles en clients-serveurs, connues dès la 
fin des années 1960, qui permettent d'organiser toutes les 
ressources que gère le système d'exploitation, explosent avec une 
approche simpliste du type un client ou un serveur =une 
machine ; ce qui fait qu'un main-frame des années 1980 se dis- 
perse en centaines, voire en milliers d'équipements. Ce qui pouvait 
se gérer en centralisé disparaît. Dans l'euphorie du « small is 
beautiful », personne ne voit venir le danger du passage de 1 
grand système « main-frame » à N systèmes en clients/serveurs 
distribués. Ceux qui osent jouer les cassandres passent pour des 
« loosers » ringards, à tel point que certains « stratèges » de bis- 
trots vont jusqu'à prédire la disparition d'IBM, quant aux autres 
constructeurs, ils sont déjà morts ! 


Nota : rappelons nous, cependant, que dans les années 1980, quelqu'un qui aurait dit 
que DEC allait disparaître purement et simplement, serait passé pour un fou ! C'est une 
histoire tragique, car DEC fut rachetée par Compaq, pour finir de sa belle mort chez HP. 


Très vite, des problèmes d'exploitation apparaissent, mais 
l'exploitation n'est jamais que la conséquence de l'architecture, et 
c'est l'architecture qui est malade. Dans une architecture distri- 
buée, il n'y a plus, par construction, de contrôle centralisé. La 
régulation de charge ne peut se faire que par échange d'informa- 
tion sur ce que les machines connaissent de leur état de saturation 
à l'instant t, ce qui fait qu'avec les temps de latence du réseau, le 
système distribué devient intrinsèquement instable, et de surcroît 
non-déterministe. La complexité de l'état global fait un formidable 
bond dans le mauvais sens. 


La nature même des applications subit une profonde métamor- 
phose. Des progiciels s'intègrent dans les systèmes d'information. 
Avec le logiciel « libre » et les composants sur étagères (c'est-à-dire 
les COTS), cette tendance s'accélère fortement dans le courant des 
années 1990. On intègre massivement, sans trop se préoccuper du 
comportement de ce que l’on intègre. D'une ingénierie d'intégration 
bâtie comme une horloge sur les main-frames, on passe à une inté- 
gration par essai-erreur tout à fait hasardeuse, indigne du code 
d'éthique d'un ingénieur correctement formé. N'ayant pris aucune 
précaution particulière, la chaîne causale DÉFAILLANCE de 
l'exploitation — DÉFAUT de programmation — ERREUR HUMAINE 
se rompt. Les défaillances non reproductibles se multiplient. Les fui- 
tes mémoire, rarissimes sur les systèmes centralisés, mais déjà 
connues en transactionnel, deviennent de plus en plus fréquentes et 
sont vécues comme une fatalité. La partie du système d'information 
programmée en interne diminue fortement, mais la taille des scripts 
de paramétrage explose, lesquels évoluent hors de tout standard et 
de toute règle de bonne programmation. En l'absence d'architec- 
ture, le SI se trouve gangrené de l'intérieur (progiciels et COTS) et 
de l'extérieur (les scripts) par toutes sortes de greffons aux 
comportements mal maîtrisés, mais il n'y a pas de système immuni- 
taire qui garantit le cohérence de l’ensemble : on fait du Frankens- 
tein sans le savoir. L'interopérabilité des systèmes, la sûreté des 
exploitations, l'évolutivité du SI deviennent des problèmes écono- 
miques majeurs. 


En d'autres termes, la technique que l’on avait fini par oublier 
revient en première ligne. Pour garantir la sûreté de fonctionnement 
d'une fédération de systèmes dans ce qu'on appelle aujourd’hui une 
architecture d'entreprise, il faut des règles précises. Ces règles doi- 
vent être rigoureusement respectées à tous les niveaux : conception 
et développement, mais aussi maintenance, support, exploitation. 
L'utilisateur lui-même, qu'il soit simple usager ou exploitant et à ce 
titre partie prenante du système, devient un maillon faible, tant ses 
comportements peuvent nuire à l'intégrité du système, d'où une 
avalanche d'aides en lignes pour l'assister et le guider, de profils 
pour distinguer le novice de l'expert, avec comme conséquence un 
surcroît de complexité de l'IHM. Il faut connaître non seulement ce 


qu'un composant ou un service fait, c'est-à-dire son aspect fonction- 
nel, mais surtout comment il le fait, c'est-à-dire ses aspects non 
fonctionnels, c'est-à-dire son comportement, dans toutes les situa- 
tions d’exécutions possibles, y compris en cas de pannes de 
plates-formes. 


Au niveau de complexité où nous sommes rendus, le bricolage 
n'est plus possible, car trop risqué. Retour, donc, au professionna- 
lisme, à la rigueur et à la compétence. C'est cela le fondement des 
méthodes agiles et de l’XP, en faisant attention aux charlatans qui, 
bien évidemment, vont continuer à spéculer sur le désarroi des 
usagers et des décideurs informatiques. 


1.2 Agilité dans le texte du manifeste 
AGILE - Les quatre valeurs de 
l'agilité 


Lors d’une réunion tenue en février 2001 aux États-Unis, les pro- 
moteurs des méthodes AGILES (voir le site www.agilealliance.org), 
appelées encore « light methodologies », ont établi un code de 
déontologie dont l'adoption définit l'appartenance à la communauté 
AGILE. Nous en donnons ici les différents éléments, en anglais origi- 
nal, accompagnés d'une traduction française libre et commentée. Le 
manifeste s'oppose aux méthodologies dites « lourdes » comme 
ISO 12207 et le modèle de développement dit «en cascade », 
ISO 9000, bien évidemment le CMM/CMMI, ISO 15288 et IEE 1220, 
etc. ; il Y a des mots très durs, par ailleurs pleinement justifiés, 
contre des normes comme la DOD 2167. L'opposition est formulée : 
soit en termes diplomatiques -— pas facile de s'opposer sans risque à 
des personnalités comme B. Boehm ou W. Humphrey - soit en 
terme de franche hostilité, à la limite de la caricature. Dans tous les 
cas, au-delà des polémiques qui sont souvent révélatrices de quel- 
que chose de profond, il est très intéressant de faire le tri. 


1.2.1 Les quatre valeurs de l'agilité 


— Valeur n° 1 (V1): /ndividuals and interactions over processes 
and tools/Individus et interactions prévalent sur les processus et 
les outils. 


— Valeur n° 2 (V2) : Working software over comprehensive docu- 
mentation/Un logiciel qui marche a plus de valeur qu'une docu- 
mentation complète. 


— Valeur n°3 (V3): Customer collaboration over contract nego- 
tiation/La collaboration avec le client prévaut sur ce qui a été 
négocié contractuellement. 


- Valeur n°4 (V4): Responding to change over following a 
plan/Répondre aux changements plutôt que de suivre le plan. 


Les auteurs du manifeste précisent qu'en tout état de cause, la 
valeur précisée à gauche a priorité sur celle de droite. 


1.2.2 Commentaires 


HC-V1 


Il est évident que processus et/ou outils, aussi géniaux soient-ils, 
ne rendront jamais un incapable intelligent. Processus et outils ne 
sont que des garde-fous, rien d'autres. Cela étant, on voit mal 
comment, à partir d'une certaine taille, on peut se passer d'un outil 
de gestion de configuration qui lui-même présuppose un cycle de 
développement quel qu'il soit. Processus et activités sont d’abord 
une typologie de tâches qui permet de savoir à quoi, pour qui, 
avec quelle finalité, les acteurs projets dépensent leur énergie. 


Pour interagir et coopérer efficacement, il faut parfaitement se 
connaître et avoir une grande confiance les uns dans les autres, ce 
qui exclut une équipe de débutants, ou une équipe dont les 
membres se méfient les uns des autres. La compétence et la soli- 
darité d'une équipe ne peuvent se construire que dans la durée. 
C'est une mécanique fragile qui peut se briser à tout instant ; de 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie 


est strictement interdite. — © Editions T.I. 


15 


H 3 202 -3 


Référence Internet 


H3202 


MÉTHODES AGILES 


plus, les équipes, comme les individus, vieillissent, et il faut se 
méfier de la sclérose qui guette toutes les organisations humaines. 


BC-V2 


Il'est évident que documenter un logiciel qui ne marche pas n'a 
aucun intérêt. Le vrai problème de la documentation des pro- 
grammes est d'expliquer pourquoi on a programmé de telle ou telle 
façon ; paraphraser le code n'apporte pas de valeur ajoutée. La docu- 
mentation doit être intégrée au programme, conformément à ce que 
D. Knuth avait appelé il y a bien longtemps la « literate 
programming ». Cela étant, on voit mal comment la maintenance, le 
support, l'exploitation pourront faire leur travail avec, comme seule 
documentation, le texte du programme. Les NTIC permettent de faire 
de très bons documents hypertextes en ligne, mais cela prend du 
temps à réaliser et exige un effort de maintenance permanent. Il n'est 
pas évident que les programmeurs soient les mieux placés pour 
documenter seuls leur programmes ; ils sont juge et partie, et par 
défaut, ils essaieront de se justifier, ce qui est humain mais inutile. 


BE C-V3 


Cela exige une maîtrise d'ouvrage mature et un cadre 
contractuel qui permet de le faire. Cela peut s'avérer très difficile 
dans des contrats gouvernementaux régis par le code des marchés 
publics. Ou alors il faut travailler en régie complète, ce qui pose 
d'autres problèmes de motivation du côté fournisseur. 


BC-V4a 


Pour changer le plan, encore faut-il que le client l'accepte, et soit 
parfaitement honnête, car en cas de difficultés ou de litiges, c'est 
le contrat qui fera foi. Pas besoin d'avoir beaucoup d'imagination 
pour trouver des situations où cela sera parfaitement impossible, 
et dangereux pour les deux parties. Le côté positif du contrat est 
qu'il oblige les deux parties à expliciter ce qu'elles attendent l’une 
de l’autre ; le contrat définit une règle du jeu, ce qui est très impor- 
tant pour faire émerger la coopération (cf. RXP2, 8 1.4). 


Les projets informatiques iraient beaucoup mieux si tous les 
acteurs du jeu se comportaient conformément à ces valeurs. Néan- 
moins, soyons lucides, nous sommes sur terre, et pas au paradis. Ce 
nirvana n'est pas pour demain. Pour que cela marche, il est impéra- 
tif que MOA et MOE aient tous deux un haut niveau de maturité, se 
fassent confiance et jouent une stratégie gagnant-gagnant. MOA et 
MOE doivent être tous deux courageux et ne pas jouer à : « c'est pas 
moi, c'est l’autre », mais il n’est pas facile d'enseigner le courage, et 
d'une façon plus générale les qualités morales (se référer au 
best-seller de Comte-Sponville [1]) ! 


1.3 Douze principes de l'agilité 
dans le texte 


Ces 12 principes sont les moteurs de l'action. Ils déterminent la 
ligne de conduite des acteurs au sein d’un projet AGILE : 

- principe n° 1 (P1) : our highest priority is to satisfy the custo- 
mer through early and continuous delivery of valuable software (la 
priorité la plus haute est de livrer rapidement et de façon continue 
du logiciel qui amène de la valeur au client final) ; 

— principe n°2 (P2) : welcome changing requirements, even late 
in development. Agile processes harness change for the custo- 
mer's competitive advantage (les modifications même tardives 
sont les bienvenues. Le procédé AGILE jugule le changement et 
donne au client un avantage compétitif) ; 

- principe n°3 (P3) : deliver working software frequently, from a 
couple of weeks to a couple of months, with a preference to the 
shorter timescale (livrer fréquemment du logiciel qui marche, à 
des intervalles de deux semaines à deux mois, avec une préfé- 
rence pour le délai le plus court) ; 

- principe n° 4 (P4) : business people and developers must work 
together daily throughout the project (les acteurs métiers et les 
développeurs doivent travailler ensemble, quotidiennement, tout 
au long du projet) ; 


- principe n° 5 (P5) : build projects around motivated individuals. 
Give them the environment and support they need, and trust them 
to get the job done (construire les projets autour d'individus moti- 
vés. Leur donner l'environnement de travail et le support dont ils 
ont besoin, leur faire confiance pour effectuer le travail) ; 

— principe n° 6 (P6) : the most efficient and effective method of 
conveying information to and within a development team is 
face-to-face conversation (la méthode la plus efficace et la plus 
sûre pour transmettre de l'information vers et à l'intérieur de 
l'équipe de développement est la discussion face à face) ; 

- principe n° 7 (P7) : working software is the primary measure of 
progress (un logiciel qui fonctionne est la mesure principale 
d'avancement du projet) ; 

- principe n° 8 (P8) : agile processes promote sustainable deve- 
lopment. The sponsors, developers, and users should be able to 
maintain a constant pace indefinitely (le procédé AGILE fait la pro- 
motion du développement durable. Le sponsor [c'est-à-dire le 
MOA, qui est intraduisible en anglais], les développeurs et les usa- 
gers devraient être capables de maintenir une allure constante 
indéfiniment) ; 

— principe n° 9 (P9) : continuous attention to technical excellence 
and good design enhances agility (une attention constante à 
l'excellence technique et à la bonne conception accroît l’agilité) ; 

— principe n°10 (P10): simplicity -the art of maximizing the 
amount of work not done - is essential (la simplicité — l'art de 
maximiser la quantité de travail à ne pas faire - est essentielle) ; 

- principe n° 11 (P11) : the best architectures, requirements, and 
designs emerge from self-organizing teams (les meilleures archi- 
tectures, les meilleures exigences et les meilleures conceptions 
émergent d'équipes auto-organisées) ; 

- principe n° 12 (P12) : at regular intervals, the team reflects on 
how to become more effective, then tunes and adjusts its beha- 
viour accordingly (à intervalle régulier, l'équipe réfléchit sur la 
façon d'améliorer son efficacité et sa performance ; ensuite, elle 
met au point et ajuste son comportement en conséquence). 


1.3.1 Commentaires 


BC-P1 


C'est ce que disent toutes les normes qualité, à commencer par 
ISO 9000 ; le problème est : comment s'y prendre ? Cela implique 
une architecture très stable et une mécanique d'intégration de haute 
précision. Il n'est pas certain, sauf dans des cas bien particuliers, 
que le client soit content de voir arriver tous les mois un morceau 
d'application. Dans de grandes organisations, une telle situation 
sera difficile à gérer à cause du nombre d'acteurs impliqués. 


HN C-P2 


En plus de l'intégration, il faut une gestion de configuration par- 
faite, depuis les exigences du client jusqu'aux tests de validation et 
de recette. Il est illusoire de se passer de gestion de configuration, 
même dans le cas d'une équipe de petite taille et très compétente 
où les concepteurs ont «tout dans la tête », car le boomerang 
reviendra lors de la maintenance, où il faudra tout reconstruire. 


BE C-P3 


Pourquoi pas ! Mais c'est à négocier avec le client. Cela corres- 
pond à un modèle d'intégration continue (cf. chapitre 4 ci-dessus). 
Ce principe présuppose que l'intégration est quasiment à la charge 
du client (voir C-P1 ci-dessus). 


B C-P4 


Cela ne peut marcher que pour des projets de petite taille, là où 
le nombre d'acteurs est limité. Au-delà d'une certaine taille, c'est le 
chaos. De plus, cela présuppose que les acteurs peuvent se 
comprendre sans difficulté et partagent tous un langage commun. 


Nota : de telle situation sont rares, sauf dans des circonstances très particulières, et 
sur une durée très limitée. Cela suppose une relation MOA/MOE idéale, or c'est le point 
faible n° 1 constaté dans de nombreux projets. 
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B C-P5 


C'est évident qu'il est préférable d'avoir des chefs de projets 
motivés et compétents. La confiance est un style de management 
qui ne se décrète pas. Le vrai problème de la confiance est sa 
limite : comment se comportent les acteurs quand ça va mal ! 
C'est là qu'il faut du courage et de l’abnégation. Par ailleurs, on 
peut être motivé et en même temps désordonné, voire obtus. La 
motivation n'est en aucun cas un substitut à la faculté d'analyse, 
de rigueur ou de l'expérience. La compétence est la résultante de 
tout un ensemble de qualités intellectuelles et morales dont le 
point d'équilibre n'est pas évident. 


BC-P6 


| C'est loin d'être une condition suffisante, mais c'est préférable. 
A l'appui de ce principe, on a pu constater que la communication 
dématérialisée via Internet engendrait des échanges parfois très 
agressifs. En cas de difficulté, il est tellement facile « d'oublier » 
les bonnes résolutions. Seuls les Japonais qui peuvent travailler 
comme cela ! Dans l'échec du projet CONFIRM [2] [3], tout le 
monde se mentait effrontément, y compris en face à face. 


BC-P7 


C'est un excellent principe, mais il ne remplace pas quelques 
bonnes métriques choisies avec intelligence. Il serait cependant 
prudent de bien définir ce que « marcher » veut dire, par exemple 
un niveau de disponibilité, un taux de couverture, un taux de 
retouches, etc. 


BC-P8 


Si c'était vrai ! Beaucoup de DSI se plaignent du manque de 
compétence des MOA et de leur incapacité à formuler clairement 
leurs problèmes. 


B C-P9 


Tout à fait exact. Cela présuppose un management de très haute 
qualité et d’un très grand professionnalisme. Il faut savoir valoriser 
la vraie performance, ce qui n'est rien moins que simple. Rien 
n'est plus démotivant pour des programmeurs que de ne pas voir 
leur savoir-faire et leur technicité reconnus. Quant à la réponse à la 
question : qu'est-ce qu'un bon design ? personne n'a la réponse, 
car l'architecture est toujours le résultat d'un compromis relatif à 
une situation particulière. 


BC-P10 


Nous reviendrons longuement sur la simplicité telle que prati- 
quée dans l'’agilité. Remarquons que rien n'est plus difficile que de 
faire simple, alors que notre tendance naturelle, surtout lorsque les 
acteurs sont nombreux, est de tout compliquer, de trouver des 


ronmnraomie doutouv l'oct nartiouliäromant diffinila à Avitar avan 


Face à la complexité, la communauté informatique aurait intérêt 
à relire les grands classiques de la cybernétique, avec J. Von 
Neumann, N. Wiener, R. Ashby, C. Shannon, J. Forrester, et regar- 
der le jargon de l'auto-organisation avec la plus grande cir- 
conspection. Cela ressemble trop à «la vertu dormitive de 
l'opium », de Molière, car donner un nom à quelque chose ne peut 
pas être un substitut à la compréhension. On n'organise pas en 
auto-organisant ; on organise en solutionnant les problèmes de 
communications et de décisions qui se posent, avec des bus 
d'échanges explicites, et en confiant la responsabilité à des gens 
compétents et courageux, c'est-à-dire un leadership. 
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Ce principe semble contredire le précédent, sur un registre 
différent, car si on « règle », c'est que l'auto-organisation n'a pas 
marché. Il est impossible de procéder au réglage des individus 
d'une équipe comme on règle des appareils. Rien n'est moins 
« réglable » que le comportement d’un individu dans un groupe. 
De plus, toute démarche d'amélioration est basée sur des 
mesures. Plutôt que d’auto-organisation, il faudrait parler de régu- 
lation, comme on le préconise dans la démarche systémique. Par 
contre, des comportements coopératifs peuvent émerger progres- 
sivement dans un groupe dont les membres pratiquent la règle du 
donnant-donnant (cf. [7]). C'est un modèle très connu de la théorie 
des jeux (voir le cahier Pour la science, juillet 1999, Les mathéma- 
tiques sociales, rubrique Des dilemmes et des stratégies), appliqué 
à des phénomènes évolutifs et comportementaux. 


1.4 Douze règles de bonnes pratiques 
de l'eXtreme Programming 


Ces règles, issues de l'ouvrage de Kent Beck sont les suivantes : 


BRXP1: Whole Team. All the contributors to an XP project - 
developers , business analysts, testers, etc. - work together in an 
open space, members of one team. The walls of this space are lit- 
tered with big visible charts and other evidences of their progress. 


L'équipe comme totalité. Tous les contributeurs d'un projet XP - 
développeurs, analystes métiers, testeurs, etc. travaillent ensemble 
dans un espace ouvert. Les murs de cet espace sont placardés 
avec les feuilles de papiers des flip-charts et les post-it qui matéria- 
lisent de façon visible à tous, la réflexion et l'évidence des progrès 
de l’équipe. 


B RXP2 : Planning Game. Planning is continuous and progressive. 
Every two weeks, for the next two weeks, developers estimate the 
cost of the candidate features, and customers select those features 
to be implemented based upon cost and business value. 


La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 


Si vous souhaitez accéder au contenu intégral de cette base documentaire, rendez-vous 


à la fin de ce document. 


Et pour toute question sur nos offres d'abonnement, n'hésitez pas à contacter le service 
Relation clientèle au 01 53 35 20 20 ou par email à l'adresse infos.clients@teching.com. 
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yant dépassé l'âge de la majorité, les technologies à objets sont largement 

sorties des laboratoires de recherche. Confrontés aux besoins multiples des 
développements en entreprise, les langages de programmation — Smalltalk, 
C++, Eiffel, plus récemment Java — se sont étoffés et diversifiés. Ils se sont 
transformés en des environnements de développement puissants, au risque par- 
fois de faire oublier la simplicité des principes sous-jacents. Ces outils, et de nou- 
veaux provenant de la pénétration des objets dans les technologies client- 
serveur, sont non seulement particulièrement efficients pour la construction 
d'applications interactives, mais permettent de répondre à la plupart des 
besoins des applications informatiques. De plus, ils savent aujourd'hui dialoguer 
avec l'informatique existante, particulièrement avec les bases de données rela- 
tionnelles déjà déployées qui, de leur côté, évoluent vers la prise en compte de 
types de données complexes proches des objets. 


Ces offres technologiques multiples proposent des solutions pour une informa- 
tique sans cesse plus hétérogène et plus distribuée dans des réseaux locaux ou 
globaux. Elles s'appuient sur la métaphore des objets actifs communiquant entre 
eux et ouvrent des perspectives pour une large (ré)utilisation de composants logi- 
ciels. Les bénéfices attendus sont des logiciels de meilleure qualité : correction, 
robustesse, fiabilité, efficacité, portabilité et extensibilité comme notées par 
B. Meyer. Ces logiciels sont plus modulaires, présentent un taux plus élevé d'uti- 
lisation de modules déjà codés, et disposent avant tout de meilleures capacités 
d'évolutivité. Celle-ci peut être définie, dans ce contexte, comme la capacité de 
modifier, de raffiner et d'étendre un ensemble existant de classes en réponse aux 
changements des besoins utilisateurs ou des contraintes opérationnelles. 
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Ces nouveaux moyens techniques, aujourd'hui d’un bon niveau de maturité, 
ne sauraient pourtant suffire à eux seuls pour satisfaire toutes les attentes mises 
sur les approches à objets. Un système informatique est un artefact, résultat 
d'une réelle activité constructive. Se pose alors la question des méthodes et des 
outils permettant de mener à bien et de maîtriser les processus de conception 
adaptés aux développements à objets. 


Comme pour la conception de tout système complexe, apparaît la nécessité de 
modèles préalables sous forme de schémas et de descriptions allant d'esquisses 
abstraites à des plans complets. Ces modèles sont les produits des activités prô- 
nées dans les méthodes dites d'analyse et de conception objet. L'objectif est 
d'aider à combler l'écart entre les besoins des utilisateurs du futur système, 
besoins exprimés sous forme textuelle, et les expressions codées des program- 
mes opérationnels. 


Plus récentes que les langages, puisque introduites au milieu des années 1980, 
les méthodes de développement à objets, du moins les anglo-saxonnes, ont 
repris la distinction analyse, conception, implémentation, empruntée à diffé- 
rents travaux de génie logiciel qui visaient pourtant une informatique procé- 
durale. L'analyse est, dans cette tradition, concernée principalement par la 
compréhension du problème à résoudre et par l'élaboration des spécifications 
fonctionnelles. La conception a pour but de produire les documents d'architec- 
ture et les spécifications détaillées du futur système informatique. 


Mais, pour l'adapter aux concepts objets, les méthodes à objets amendent 
cette distinction selon plusieurs points de vue. D'une part, elles voient générale- 
ment ces différentes étapes comme des macroactivités n’imposant pas un cycle 
de vie particulier (cycle en V, W, spirale, etc.), mais pouvant relever de processus 
variés. Ceux-ci doivent être adaptés aux spécificités de l'application et de l’entre- 
prise concernées. Ces méthodes rejoignent par là les réflexions les plus avan- 
cées en génie logiciel. D'autre part, nous verrons que la proposition d'utiliser les 
concepts objets pour chaque phase (« cycle de vie tout-objet ») implique de 
repenser aussi bien le contenu de chacune, particulièrement l'analyse, que les 
processus de transformations entre les différentes étapes. L'utilisation de repré- 
sentations similaires ou uniformes durant tout le cycle est proposée par presque 
toutes ces méthodes. Les avantages provenant de cette uniformité sont 
certains : simplicité, compréhensibilité, réutilisation des prototypes développés, 
etc. [Is ne doivent néanmoins pas être surestimés au point d'entretenir l'illusion 
d'un processus linéaire qui relèverait uniquement de règles de transformation 
automatiques ou, mieux, complètement automatisables. D'autant que le pas- 
sage progressif à une informatique à base de composants ne peut pas manquer 
d’avoir des conséquences importantes sur les processus de développement à 
objets. 


Quoi qu'il en soit, de nombreuses méthodes de génie logiciel adaptées aux 
objets ont été proposées. Elles connaissent encore à cette date des évolutions et 
des convergences, même si les processus de standardisation sont en bonne 
voie. Ces méthodes doivent être considérées suivant plusieurs dimensions. 
D'abord on s'intéressera à l'ensemble des concepts et notations utilisés. Ensuite, 
ces méthodes doivent proposer un processus pour leur mise en œuvre qui doit 
inclure l’ensemble de tâches à effectuer avec les produits de chaque étape ainsi 
que les dépendances entre ces tâches et les différents éléments constituant les 
modèles produits. Enfin ces méthodes décrivent les aspects organisationnels à 
considérer pour l'obtention de logiciels de qualité. Malgré certaines lacunes, 
elles montrent, dans leur diversité, que l'impact des concepts objets dépasse les 
langages et que c’est l'ensemble du cycle de développement qui est transformé 
par ces nouvelles approches. 


Qu'ils soient formalisés ou non, les résultats des différentes activités des 
méthodes à objets sont différents modèles construits en vue d'objectifs spécifi- 
ques. Dans les phases amont, ces modèles sont plus descriptifs et plus abstraits, 
avec comme point d'appui une modélisation d'un domaine externe. Dans les 
phases aval, ils doivent être prescriptifs et opérationnalisables, modèles du sys- 
tème informatique en construction. Les modèles produits doivent être situés par 
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rapport à ces deux nécessités ; suivant l'expression de Marc Linster, on pourra 
parler de « modélisation pour conférer du sens et de modélisation pour 
construire un système opérationnel ». Par rapport à ces deux objectifs, les quali- 
tés majeures attendues sont différentes. Pour le premier, la compréhensibilité et 
la capacité de rendre compte du domaine sont prioritaires. Pour le second, la 
facilité de la transposition en machine est fondamentale. L'ambition des appro- 
ches objets est de répondre à ces différentes nécessités à partir du même 
ensemble de concepts, les qualités des phases amont devenant les atouts prin- 


cipaux des phases aval. 


Nota : pour de plus amples détails sur les travaux des auteurs cités dans cette introduction, on pourra se 


reporter aux références [1] [3]. 


1. Une nouvelle manière 
de concevoir 
et de développer 


1.1 Les concepts communs 
aux approches objets 


Les approches objets — langages de programmation, bases de 
données, systèmes distribués, intelligence artificielle, etc., — peu- 
vent être caractérisées par la mise en œuvre d’un ensemble 
commun de concepts, même si des analyses plus approfondies 
montrent que chacune de ces approches en donne sa propre inter- 
prétation [4]. On se contentera de rappeler ici l'essentiel de ces 
concepts, afin de faciliter la compréhension des sections suivantes. 
Nous avons choisi la terminologie la plus usitée, sans signaler dans 
chaque cas toutes les appellations parfois encore en usage. C’est sur 
une bonne compréhension et une bonne mise en œuvre de ces con- 
cepts [5] que repose la manière de penser et de concevoir objet dont 
les méthodes du génie logiciel dédiées à ces approches ne sont ou 
ne devraient être qu'une tentative de traduction pragmatique. 


B Les objets 


Un objet, qui a une identité, encapsule les données qui lui sont 
propres et les opérations qu'il peut mettre en œuvre. Ses données, 
accessibles seulement par les champs de l'objet, décrivent son état 
à un moment particulier. Grâce à l'encapsulation, leurs change- 
ments, donc celui de l'état de l’objet, ne peuvent être effectués direc- 
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tions des classes contiennent non seulement la liste des noms des 
champs mais aussi les textes des méthodes qui sont, par hypothèse, 
communes à toutes les instances d’une même classe. Ces méthodes 
définissent donc les comportements communs aux instances et 
correspondent aux responsabilités attribuées aux objets de cette 
classe. On parlera aussi des services rendus par ces objets. 


On fera généralement le choix de construire le premier ensemble 
de classes en s'appuyant sur les principales entités du domaine 
applicatif. On assure ainsi une meilleure stabilité de ce noyau initial 
ainsi qu'une meilleure compréhensibilité. Ainsi, les comptes, les 
transactions bancaires ou les clients sont des objets de la banque, 
comme les contrats ou les assurés pour l'assurance. Cet ensemble 
de classes, produit de l'analyse du domaine, est une des entrées 
principales pour la construction de la solution technique. 


Par la suite, nous nous limiterons aux approches utilisant ces 
notions de classe et d'instance. Ce sont, dans les technologies à 
objets, les seules qui, à ce jour, ont donné lieu, d'une part à des 
applications significatives, et d'autre part à des supports méthodo- 
logiques réels, sujet de cet article. Soulignons que, dans de telles 
approches, la conception des classes est l'aspect essentiel : un objet 
n'existe que comme instance d’une classe préalablement définie. 


e Les approches à objets donnent la possibilité de déclarer une 
classe comme sous-classe d'une autre. Cela permet d'une part de 
donner une certaine traduction informatique des mécanismes 
cognitifs de classification de concepts suivant leur degré d'abstrac- 
tion, d'autre part d'offrir un mécanisme puissant de partage de code 
dans l'implémentation. Une sous-classe hérite par défaut de tous les 
éléments constitutifs de sa classe parente, champs et opérations, et, 
par transitivité de l'ensemble de ses surclasses directes ou indirec- 
tes. Pour éviter une trop grande rigidité, les propriétés d’une sur- 


La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 


Si vous souhaitez accéder au contenu intégral de cette base documentaire, rendez-vous 


à la fin de ce document. 


Et pour toute question sur nos offres d'abonnement, n'hésitez pas à contacter le service 
Relation clientèle au 01 53 35 20 20 ou par email à l'adresse infos.clients@teching.com. 


Février 2004 


Référence Internet 
H3238 


Langage UNIL : développement 
de logiciel et modélisation visuelle 


par Patrick GIROUX 


Ingénieur consultant, EADS Defence and Security Systems 
Maître de conférence associé, université de Rouen 


1. Modélisation en génie logiciel …...….........…........…...…....…........................ H3238-2 
2. Origine et objectifs d'UMEL ............................................................. — 3 
3. Fondements et concepts de base... — 4 
4. Modélisation statique …......................…...…........................................... — GS 
41! Diagramme de classes 252 sissshiiiieneiienetretieieeenesnes — G 

AMPASSOCIATIOM EE LE rer ne raser tar et en en Air lre te ee Lt Rte letter — 5 

4.1.2 Agrégation et COMPOSITION sr — 6 

4.1.3 Spécialisation/généralisation...................................................... — 6 

4.1.4 Précisions de modélisation et notations complémentaires — 6 
4.2. . Diagramme d'objets: mrsrnrriariensessmteransiaersoneheiseneesenanéinetenesseneee — 8 
5. Modélisation fonctionnelle .…...................................................... — 8 
DA CAS IUTIIIS ATOME ARR M AR Sn a a te tree at ns a Ste n sc — 8 
Di2: L'ACTOUNS:.: nr entree nt es apnsrnee rasta dieser este nnr srl nat inde nes seat least nées tone — 9 
5.3 Diagramme de cas d'utilisation... — 9 
5.4 Intérêt méthodologique des cas d'utilisation... — 10 
6. Structuration de modèle..…............................................................ — 11 
6.1 Notion de paquetage — 11 
6.2 Modélisation d'architecture... ss. — 12 
7. Modélisation d'interactions entre objets. — 13 
HAL SCÉNMATIO En marient lets rene rentre 2 — 13 
1:2: 1Diagrammes'd'INtTérACtIONS:-. 22.22.1222 cesser eestes ete esneisss terasse se secessesee — 14 

7.2.1 Diagramme de séquence ss — 15 

7.2.2 Diagramme de collaboration... — 16 
8. Modélisation dynamique..…............…............…................................... — 16 
811. DIagrammMeQlétais 27222 rrrsrsnseseerarcre tete ras ramss rene e res s tds etes cat sets i oo — 16 
8:2 Diagramme d'activités. cuirnrienienersrnerannetstessaneititenensenarénennteetennee — 18 
9. Modélisation d'architecture....…...…........….......................................... — 18 
91 Diagramme de COMPOSANIS re erres se ses ere rein ssse see sie esse — 18 
9.2 Diagramme de déploiement... — 19 
10. Extensibilité et ouverture .…...…............................................................... — 20 
LEE 0 | 1 PR — 21 
POUr On SAVOIT PIUS 1221122215 1a1srrssserensasenss tic ass eaonsinssitasssoncssessescessantenateasoee Doc. H 3 238 


e langage UML (Unified Modeling Language) est un langage graphique de 
modélisation initialement conçu pour représenter, spécifier, concevoir et 
documenter les artefacts de systèmes logiciels. Adopté par l’'Object Manage- 
ment Group (OMG) en tant que standard, il est devenu une référence incon- 
tournable dans le domaine du génie logiciel. Sa richesse et sa puissance 
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d'expression le rendent également éligible pour la modélisation de concepts et 
de processus « métier » (« business modeling ») et pour l'ingénierie de systèmes 
non logiciels. UML résulte de l'unification de techniques ayant fait leurs preuves 
pour l'analyse et la conception de grands logiciels et de systèmes complexes. 


UML intègre neuf types de diagrammes destinés à la caractérisation du sys- 
tème modélisé et à la représentation des éléments qui le constituent : 


— les diagrammes de cas d'utilisation permettent de décrire les fonctionnali- 
tés du système et de représenter les différents types de sollicitations auxquelles 
il doit pouvoir répondre ; 

— les diagrammes de classes sont destinés à décrire les propriétés structu- 
relles des objets du monde réel, les concepts spécifiques du domaine considéré 
ou encore les notions abstraites que le système doit appréhender. Ce sont les 
diagrammes le plus fréquemment utilisés en modélisation orientée objet. En 
phase de conception du logiciel, ils sont exploités pour décrire l'architecture 
statique du système et les interdépendances entres ses constituants ; 

— les diagrammes d'objets offrent un moyen de représenter les objets 
(c'est-à-dire les instances des classes figurant dans les diagrammes de classes) 
ainsi que leurs relations ; 

— les diagrammes de collaboration permettent de formaliser les scénarios de 
mise en œuvre du système et de montrer comment les objets sont mis en jeu 
pour réaliser les cas d'utilisation. Ils décrivent les interactions entre les objets ; 

— les diagrammes de séquence, comme les diagrammes de collaboration, 
décrivent les interactions entre objets. Ils mettent l'accent sur l'ordre chronolo- 
gique dans lequel s'effectuent les échanges de messages entre objets ; 

— les diagrammes d'états (ou diagrammes états-transitions) apportent le 
complément nécessaire à la formalisation des aspects dynamiques : ils répon- 
dent au besoin de modéliser les processus d'exécution et les comportements 
des objets en réaction aux stimuli auxquels ils sont soumis ; 

— les diagrammes d'activités sont également dédiés à la représentation de 
l'exécution d'un processus : ils constituent une variante des diagrammes 
d'états ; 

— les diagrammes de composants sont destinés à la description des éléments 
de configuration qui constituent le logiciel (binaires exécutables, bibliothèques, 
unités de compilation, etc.) et à la formalisation de leurs dépendances ; 

— les diagrammes de déploiement permettent, enfin, de représenter l’implan- 
tation des différents programmes et composants logiciels sur l'architecture phy- 
sique du système. 

À travers quelques exemples simples, le présent article décrit la syntaxe du 
langage UML pour chacun de ces diagrammes et tente de délimiter leurs 
champs d'application dans un processus de développement de logiciel. 


1. Modélisation en génie 
logiciel 


La modélisation est une activité technique qui s'inscrit dans de 
nombreux processus d'ingénierie. Son but est de fournir une 
représentation approchée du système ou du produit que l’on veut 
analyser, concevoir ou fabriquer. Cette représentation, appelée 
modèle, contribue à l'étude des caractéristiques techniques du sys- 
tème, des phénomènes relatifs à son fonctionnement ou encore de 
son architecture. 


L'élaboration d'un modèle est souvent motivée par une 
complexité importante du système étudié. Du fait de cette 
complexité, il est difficile, voire impossible, de représenter le sys- 
tème globalement et exhaustivement avec un niveau de détail suf- 
fisant pour le comprendre, le définir ou le documenter. De façon 
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générale, les modèles relèvent donc d’abstractions, c'est-à-dire 
qu'ils sont élaborés par rapport à l'ensemble restreint des proprié- 
tés que l’on veut étudier. Les caractéristiques secondaires sont 
volontairement occultées ou masquées afin de limiter la 
complexité. Un modèle peut intégrer différentes vues qui corres- 
pondent à des abstractions particulières et à des représentations 
distinctes, complémentaires et cohérentes. Dans certains cas, le 
développement d'un système peut même nécessiter l'élaboration 
de plusieurs modèles distincts portant sur des champs d'abstrac- 
tion différents en fonction de l'avancement du processus. 


Si le problème est simple, la solution peut résulter d'une intui- 
tion, d'une idée ou d'une simple réflexion intérieure. Si le pro- 
blème est plus complexe, une tendance naturelle est d'utiliser un 
support écrit pour exprimer la solution et le cheminement intellec- 
tuel dont elle découle. Ce support peut alors servir pour raisonner 
et pour évaluer la solution envisagée puis pour la compléter, 
l'améliorer et la préciser jusqu'au niveau de détail voulu. La forma- 
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lisation écrite de la solution devient alors une référence qui va gui- 
der le processus de réalisation : l'objectif est de concrétiser la 
solution élaborée en s'appuyant sur l'expression qui en a été faite. 
Si le concepteur et le réalisateur sont des individus distincts qui 
interviennent au sein d'une même équipe, le support écrit qui for- 
malise la solution devient également un vecteur de communication 
indispensable. 


La complexité du processus d'ingénierie, la difficulté afférente au 
problème posé et les enjeux liés à la résolution de ce problème 
induisent donc des besoins plus ou moins forts de modélisation. 
La fabrication d'une cabane, la construction d'une maison particu- 
lière et la réalisation d'un grand ensemble immobilier n'engen- 
drent pas les mêmes exigences en matière de modélisation et de 
formalisation. Si un simple croquis suffit dans le premier cas, un 
plan d'architecte est nécessaire dans le second alors qu'une 
maquette à échelle réduite sera parfois élaborée dans le troisième. 
Bien entendu, le génie logiciel n'échappe pas à cette règle et à cha- 
que stade du processus de développement, la modélisation pré- 
sente un intérêt particulier plus ou moins important en fonction de 
la complexité et de la taille du logiciel. 


En phase d'analyse, l'intention première est de comprendre. Il 
s'agit de modéliser sans déformer la réalité en recherchant avant 
tout l'exactitude et la précision du modèle. L'analyse est une phase 
de découverte et le modèle doit formaliser les notions que l'ana- 
lyste perçoit et cherche à caractériser afin de mieux les étudier. 
L'analyste est avant tout un observateur et le modèle qu'il élabore 
est une représentation de ce qu'il a observé. En phase de concep- 
tion, le but est d'imaginer une solution susceptible de répondre à 
un problème connu et exprimé. La conception est une phase 
d'invention et le modèle décrit les éléments de la solution propo- 
sée. || permet de confronter cette solution au problème initial. Le 
concepteur est un créateur et le modèle qu'il élabore est une repré- 
sentation du système qu'il a imaginé. En phase de réalisation, 
l'objectif est de donner corps à la solution retenue à l'issue de la 
conception. La réalisation est une phase de concrétisation et le 
modèle doit expliciter les décisions techniques et les choix effec- 
tués lors de l'élaboration des programmes. Le modèle sert égale- 
ment à documenter le logiciel pour faciliter sa maintenance et sa 
réutilisation. Le réalisateur est un expert du langage de program- 
mation et le modèle qu'il élabore porte sur la structure des pro- 
grammes et sur leurs modalités de mise en œuvre. 


On constate donc que, en règle générale, l'objectif de la modéli- 
sation est centré sur la compréhension et la communication. Pour 
atteindre cet objectif, l'activité de modélisation doit être conduite 
selon un certain nombre de principes : 


— le modèle doit contribuer à la simplification du problème 
posé et il doit présenter la solution de façon synthétique : un 
modèle complexe est, a priori, Un mauvais modèle ; 

— le modèle doit être facile à comprendre (en totalité ou en par- 
tie) par un lecteur qui n'a pas participé à son élaboration. Il doit 
donc répondre à des critères de lisibilité et de modularité et il doit 
être présenté de façon pédagogique, par exemple, selon une 
approche descendante, en allant du général au détaillé ; 

— le modèle doit pouvoir être facilement complété, modifié, 
adapté en fonction des progrès de l'étude et au gré des besoins 
engendrés par les demandes d'évolution et les choix techniques 
réalisés ; 

— le modèle doit pouvoir illustrer la solution et contribuer à la 
documentation de celle-ci : il est souvent l'élément central d'un 
document d'analyse ou de conception. 


Le besoin de communiquer et les orientations pratiques relevant 
de ces principes amènent naturellement à la nécessité de forma- 
liser les concepts et les idées issus du processus d'ingénierie. Pour 
ce faire, la création d'un langage commun compréhensible par 
tous les acteurs du processus devient indispensable. Par ailleurs, 
l'utilisation d'un langage graphique et les approches de modélisa- 
tion « visuelle » (visual modeling) présentent de nombreux avan- 
tages en ce qui concerne les principes cités plus haut : simplicité, 
universalité, concision, capacité d'expression, etc. 
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2. Origine et objectifs d'UML 


Dans le domaine du génie logiciel, l'avènement des technologies 
objets a coïncidé avec le besoin impérieux de rationaliser le pro- 
cessus de développement. Ce besoin s'est révélé au travers des 
difficultés à maîtriser le développement des produits logiciels de 
taille et de complexité croissantes. Il s'en est suivi une prolifération 
de méthodes O0 (orientées objets) censées apporter des réponses 
en terme de modélisation tant au niveau de l'analyse que de la 
conception (moins de 10 méthodes recensées en 1989 ; plus de 50 
en 1994). Face à une telle diversité, les choix s'avèrent souvent dif- 
ficiles pour les utilisateurs et les querelles d'experts ne font que 
compliquer la problématique de sélection. La disparité des métho- 
des est, bien sûr, un lourd handicap lorsqu'un projet nécessite la 
collaboration de plusieurs intervenants et l'introduction d'une nou- 
velle méthode dans l'organisation engendre des coûts d'appropria- 
tion souvent très importants. La standardisation apparaît donc 
comme l'unique moyen d'homogénéiser et de sécuriser les choix 
tout en apportant une garantie de pérennité. 


À l'origine d'UML se trouvent les deux méthodes les plus utili- 
sées dans le monde au début des années 1990: OMT (Object 
Modeling Technique) de J. Rumbaugh [1] et OOD (Object-Oriented 
Design) de G. Booch [2]. 


Grady Booch rejoint la société américaine Rational dès le début 
des années 1990. Il travaille à l'élaboration de la méthode nommée 
OOD qui propose une notation graphique à base de « nuages » 
permettant de représenter les classes et les objets selon différentes 
visions (statique/dynamique, logique/physique). En 1991, James 
Rumbaugh, Mickaël Blaha et quelques autres ingénieurs du centre 
de recherche de General Electric aux États-Unis publient un livre 
intitulé Object Oriented Modeling and Design [1] dans lequel ils pré- 
sentent les fondements de la méthode OMT. En France, Philippe 
Desfray et la société Softeam définissent la méthode classe-rela- 
tion supportée par l'outil Objecteering : un premier livre est publié 
en 1992 [3]. De 1991 à 1994, toutes ces méthodes évoluent progres- 
sivement et gagnent en maturité au fil des expériences et des pro- 
jets. De nouvelles versions de OOD et OMT-2 se font jour en 1993. 


En 1994, J. Rumbaugh rejoint G. Booch chez Rational et, en 
octobre 1995, ils publient ensemble un draft version 0.8 de la 
méthode unifiée qui est largement diffusé et soumis à la critique 
des utilisateurs. Fin 1994, c'est au tour d'lvar Jacobson, auteur de 
la méthode OOSE (Object Oriented Software Engineering), appelée 
aussi Objectory, et des techniques de modélisation par cas d'utili- 
sation, de rejoindre Rational pour apporter sa contribution au tra- 
vaux d'unification. 


Un nouveau draft 0.9 paraît en juin 1996 immédiatement suivi de 
la version 0.91 en octobre 1996. Cette version marque un tournant 
dans le processus d'unification. La méthode unifiée devient UML. 
Les travaux se recentrent donc sur la définition d'un langage de 
modélisation graphique et textuel qui se veut universel. La norma- 
lisation du processus devient un objectif de second plan et la prio- 
rité est donnée à la formalisation du modèle, indépendamment du 
processus ayant conduit son élaboration. UML est destiné à per- 
mettre la présentation du résultat sous une forme compréhensible 
par le plus grand nombre sans présumer des moyens mis en 
œuvre pour le produire. 


Dans ce premier temps, le processus d'unification repose essen- 
tiellement sur une consolidation de l'existant. L'optique prise est 
plutôt de reprendre les techniques qui existaient dans les méthodes 
OMT, Booch et OOSE et de les mettre en cohérence plutôt que d'en 
créer de nouvelles. Il s'agit donc bien de travaux d'unification 
conformément à ce que laisse présager le terme « Unified ». 


En 1996, quelques grandes sociétés informatiques (DEC, HP, 
I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, 
Microsoft, Oracle, Texas Instrument et Unisys) rejoignent Rational 
sur le projet UML et fondent l'UML Partners Consortium pour tra- 
vailler à sa définition. 
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À cette même époque, une task force « Analysis & Design» se 
met en place à l'OMG, autre consortium réunissant quelque six 
cents sociétés concernées par les technologies objets et supportant 
une mission de normalisation. Ce groupe de travail lance un appel 
à soumission auquel l'UML Partners Consortium répond en 
janvier 1997 avec la version 1.0. La version 1.1, qui prend en 
compte un certain nombre de remarques, est publiée en septem- 
bre 1997 et retenue par l'OMG dès le mois de novembre de cette 
même année. À partir de ce moment, UML ne cessera plus de se 
diffuser dans tous les domaines liés directement ou indirectement 
au logiciel et aux systèmes d'information. 


Outre la satisfaction du besoin lié à la communication, la norma- 
lisation de la notation s'avère être un élément fondamental pour 
l'intégration des outils d'analyse et de conception objet dans 
l'entreprise. L'existence d'UML permet d'envisager la mise en place 
de passerelles permettant d'échanger les données de modélisation 
entre différents outils. Il devient donc possible de travailler dans 
des contextes multioutils où chaque industriel, voire chaque 
équipe, peut utiliser l'outil de son choix en fonction des critères 
qu'il juge pertinents : coût, stratégie société, ergonomie, adéqua- 
tion au besoin technique, etc. 


À partir de la version 1.3, les travaux menés à l'OMG s'orientent 
vers l'industrialisation du langage et, parallèlement, ils vont 
s’efforcer d'intégrer des concepts et des mécanismes destinés à 
faciliter et à généraliser son utilisation. 


En 2003, la spécification de la version 2.0 est disponible sur le 
site Web de l'OMG. 


3. Fondements et concepts 
de base 


Selon le « paradigme objet », un système peut être vu comme 
un ensemble fini d'objets qui collaborent pour assurer une mission 
globale. Chaque objet intervient dans cette collaboration selon un 
modèle comportemental particulier que l'on spécifie par l'intermé- 
diaire d'une classe. Le principe de classification amène à considé- 
rer que deux objets distincts régis par un même modèle 
comportemental appartiennent à la même classe. Dans le modèle 
objet, outre un moyen de définir les caractéristiques et le compor- 
tement propres à un sous-ensemble des objets du système, la 
classe est aussi une structure dédiée à la création (instanciation) 
des objets de ce sous-ensemble. 


Exemple : pour dessiner une figure géométrique simple, il faut, en 
premier lieu, savoir à quelle catégorie elle appartient. Est-ce un carré ? 
Un cercle ? Un triangle ? Indépendamment de la taille, de la couleur et 
de l'épaisseur du trait, la forme générale et la méthode de dessin de la 
figure sont, bien entendu, fonctions de la classe à laquelle elle appar- 
tient. La définition précise de la classe des cercles devra donc permet- 
tre de reproduire le dessin d'un cercle autant de fois que nécessaire en 
appliquant chaque fois le même procédé et en particularisant l'instance 
par des attributs de taille et de couleur. Les différentes catégories de 
figures géométriques pourront être organisées selon une structure hié- 
rarchique basée sur la classification. Ainsi, la classe des carrés sera 
considérée comme une sous-classe des rectangles qui sera elle-même 
vue comme une sorte de quadrilatère. On pourra procéder soit par 
généralisation (définir la classe de quadrilatères en généralisant la 
notion de rectangle, de losange, de trapèze, etc.), soit par spécialisation 
(définir la classe carré en spécialisant le rectangle). L'emploi du lien 
«est une sorte de » permettra de définir de nouvelles classes en pro- 
cédant par analogie avec d'autres classes, les classes spécialisées héri- 
tant des propriétés des classes générales. Un modèle plus riche de la 
géométrie pourra inclure des notions de point, de plan, de repère, etc., 
et la réalisation d'un schéma géométrique pourra se ramener à l'invoca- 
tion de la méthode « dessiner » sur un ensemble particulier 
d'instances des différentes sous-classes de figures géométriques. 
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Partant de ce principe, un objet peut donc toujours être consi- 
déré comme l'instance d'une classe et l'objectif fondamental d'une 
approche de modélisation orientée objet consiste en l'identification 
et la formalisation des classes d'objets utiles et nécessaires pour le 
fonctionnement du système. La difficulté majeure de la modélisa- 
tion orientée objet réside précisément dans la recherche et la sélec- 
tion des classes d'objets nécessaires au fonctionnement du 
système. Si le langage UML répond parfaitement au besoin de for- 
malisation, il n'apporte, en revanche, aucune aide en ce qui 
concerne l'identification des classes et des objets. Ce travail diffi- 
cile est de la seule responsabilité de l'ingénieur ou de l'analyste qui 
doit recenser les notions émergentes de l'étude pour les traduire 
conceptuellement. En résumé, l'utilisation d'UML ne garantit en 
rien la qualité du modèle. 


De façon générale, les différents éléments qui permettent de 
caractériser les objets d'une classe sont appelés les membres de 
classe et se divisent en trois catégories : 


— les attributs, qui décrivent les données représentatives d'un 
objet de la classe et qui permettent de lui associer des valeurs 
propres (variables d'instance) ; 

— les opérations ou méthodes, qui décrivent les services offerts 
par chaque objet de la classe et qui peuvent être invoquées pour 
modifier l'état interne de l'objet ; 

— les relations qui décrivent les liens avec les autres objets 
appartenant éventuellement à d'autres classes et qui traduisent 
donc les interdépendances entre les classes. 


Exemple : dans le cas de la figure géométrique, le procédé de 
dessin sera modélisé par une méthode, les caractéristiques de taille et 
de couleur seront des attributs et on pourra mettre en relation un 
triangle et son cercle circonscrit par l'intermédiaire d'une association. 


Une caractéristique essentielle d'un membre de classe concerne 
sa visibilité. Cette propriété permet de savoir si d'autres classes 
peuvent connaître et utiliser l’attribut, l'opération ou la relation. On 
distingue trois niveaux de visibilité : 


— la visibilité d'un membre de classe est publique lorsque tous 
les objets du système peuvent y accéder (n'importe quel objet peut 
invoquer une opération publique, connaître ou modifier la valeur 
d’un attribut public et accéder aux instances mises en jeu par une 
relation publique) ; 

— la visibilité d'un membre de classe est privée lorsque seul 
l'objet qui la définit y a accès (par exemple, une opération privée 
ne peut être invoquée que par l'objet lui-même) ; 

— la visibilité d'un membre de classe est protégée lorsqu'il est 
accessible uniquement aux autres objets de la classe et aux objets 
de classes dérivées (c'est-à-dire les classes qui sont définies par 
spécialisation de la classe considérée). 


Le principe d'encapsulation, largement répandu en génie logi- 
ciel, amène à proscrire l'utilisation de visibilité publique pour les 
attributs et les relations. Seul l’objet lui-même peut accéder et met- 
tre à jour les valeurs caractéristiques de son état courant. Si cette 
règle est respectée, la connaissance et la mise à jour d’un attribut 
ou d’une relation définie par une classe d'objet ne peuvent se faire 
que par l'intermédiaire d'une opération publique de cette classe. 


En UML, tous les éléments de modélisation qui peuvent être ins- 
tanciés sont nommés, de façon générique, des classificateurs. La 
classe est le principal classificateur mais il en existe d'autres tels 
que le type, le composant, l'interface, etc. On distingue le concept 
de type et celui de classe : la classe est la réalisation d'un type par- 
ticulier et en a donc toutes les caractéristiques mais elle corres- 
pond à une implémentation particulière. Le type est décrit par des 
caractéristiques comportementales qui déterminent une interface 
mais il peut exister plusieurs implémentations de cette interface. 
La classe est la réalisation de l'interface au travers d'une implé- 
mentation particulière. 


Les membres d'un classificateur peuvent également être carac- 
térisés par leur portée : soit ils concernent uniquement l'instance, 
ce qui signifie que chaque objet se caractérise par des valeurs 
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propres, soit ils concernent la classe toute entière, ce qui veut dire 
qu'ils ne possèdent qu'une valeur pour l'ensemble des instances. 
Par exemple, le dénombrement des instances d’une même classe 
pourra être réalisé par une opération de classe. 


4. Modélisation statique 


4.1 Diagramme de classes 


En UML, la classe est représentée par un rectangle dans lequel 
figurent les labels et les éléments textuels qui décrivent ses carac- 
téristiques. Le rectangle représentant la classe en UML peut être 
scindé en trois : le compartiment supérieur contient le nom de la 
classe, le compartiment du milieu contient la liste des attributs et 
le compartiment inférieur contient la liste des opérations. Seul le 
compartiment supérieur est obligatoire. Les attributs peuvent être 
typés et les signatures des opérations peuvent être également spé- 
cifiées dans une syntaxe proche de celle des langages de program- 
mation. UML définit un certain nombre de types élémentaires 
(entier, réel, chaîne de caractères, booléen, etc.). La figure 1 pré- 
sente différentes notations possibles pour une classe modélisant 
l'ensemble des coordonnées géographiques. 


On peut distinguer plusieurs types de relations entre classes : 
l'association, l'agrégation, la spécialisation/généralisation, la dé- 
pendance. 


4.1.1 Association 


L'association traduit un lien structurel entre les objets des 
classes considérées. Dans la grande majorité des cas, une asso- 
ciation permet de mettre en relation des objets appartenant à deux 
classes différentes mais elle peut aussi être utilisée pour lier entre 
eux les objets d'une même classe. Une association se caractérise 
par : 

— un nom qui exprime l'idée du lien modélisé ; 

— les rôles joués par les objets impliqués dans chacune des 
classes ; 

— les cardinalités qui précisent le nombre d'objets impliqués 
dans chacune des classes ; 

— l'orientation, ou navigabilité, qui permet de préciser les 
modalités de parcours du lien d'association. 


Le modèle de la figure 2 indique qu'il existe une association 
entre la classe Coordonnee Geo et la classe Mobile. Cette associa- 
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Coordonnee Geo 


latitude 
longitude 
altitude 


Coord Geo() 
altitude() 

valider() 
formater() 
calculerDistance() 


Coordonnee Geo 


Coordonnee Geo 


- latitude : Long 
- longitude : Long 
- altitude : Long 


+ Coord Geo(lat : Long, long : Long) 

+ altitude() : Long 

+ valider() : Boolean 

+ formater() : String 

+ calculerDistance(o : Objet Geo) : Long 


Figure 1 - Représentations de la classe Coordonnee Geo en UML 


à une même instance de la classe Coordonnee Geo. Ces infor- 
mations de cardinalité sont mentionnées sur le diagramme par 
l'intermédiaire du nombre minimum et du nombre maximum 
d'instances mises en jeu. Dans le cas présent, un mobile a une 
coordonnée géographique au plus et celle-ci peut ne pas être 
connue (notation 0.1). Par ailleurs, plusieurs mobiles peuvent être 
positionnés à la même coordonnée (notation “). 

Nota : au contraire du modèle de données de Merise, les indications de cardinalité sont 
mentionnées sur le diagramme, à l'intersection du lien et de la classe correspondant aux 
instances concernées 

Dans le cadre de ce même modèle, le lien d'association ne peut 
être parcouru que du mobile vers la coordonnée : chaque instance 
de Mobile gère donc une référence sur l'instance de Coordonnee 
Geo qui lui est associée mais il n'existe pas de lien direct d’une ins- 
tance de Coordonnee Geo vers l'instance de Mobile. Cette indica- 
tion est fournie par une flèche allant de la classe Mobile vers la 
classe Coordonnee Geo. De façon générale, on dit que les associa- 
tions sont « navigables » et on exploite le sens de navigation pour 
s'assurer que l’on peut accéder à un objet en parcourant l'associa- 
tion qui le lie à un autre objet. Par défaut, l'association est navi- 
gable dans les deux sens et l'absence de flèche peut donc exprimer 
une relation mutuelle entre les deux classes. 
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L ‘impact critique de l'analyse des exigences sur la qualité du logiciel a été 
reconnu de longue date et à maintes reprises. Des enquêtes récentes en 
Europe et aux Etats-Unis ont confirmé le problème à une plus grande échelle. 
Les échecs de projets SI sont imputables dans un cas sur deux au manque de 
qualité du document d'exigences. 


Améliorer la qualité de ce document, ainsi que la pratique de l'Ingénierie des 
Exigences (IE) est donc un objectif primordial. Cet objectif n'est pas facile à 
atteindre, au vu du large spectre de considérations à couvrir, de la multitude 
de processus et produits concernés, de la multitude d'acteurs à impliquer, et 
de la variété d'écueils à éviter. L'IE est une discipline aux confins du génie logi- 
ciel et de l'ingénierie des systèmes, qui vise à offrir des modèles, méthodes et 
outils pour développer et faire évoluer des documents d’exigences de qualité. 
Cet article se propose de donner un aperçu des développements récents dans 
cette discipline relativement jeune et d'en approfondir certains. L'IE élargit 
l'approche classique où l’on cherche à comprendre, ce qui doit être réalisé par 
le système en essayant de comprendre le « pourquoi » du système, sa raison 
d’être. 

L'expression du « pourquoi » est faite en termes de buts organisationnels et 
de leur impact sur les exigences imposées au système d'information. L'article 
insiste sur cette dimension, propose et illustre, par une étude de cas, une 
démarche d'ingénierie des exigences dirigée par les buts. 
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domaine de l'IE. La notion d'exigence comme nouvelle forme 
d'expression du contenu du traditionnel cahier des charges est 
introduite et développée en paragraphe 3. Le paragraphe 4 pré- 
sente les clés des approches d'IE dirigées par les buts et les illustre 
par des exemples variés. Le cas des réservations de chambres 
d'hôtels est traité en paragraphe 5. Le paragraphe 6 conclut 
l'article par un résumé des notions et démarches qui y ont été 
développées. 


1. Position de l'ingénierie 
des exigences 


Les approches traditionnelles d'ingénierie des Systèmes d'Infor- 
mation (SI) se fondent sur l'hypothèse qu'un SI représente une 
partie du monde et de ce fait, se focalisent sur la modélisation de 
l'information représentative de « l'Univers du Discours » que le 
système doit rendre accessible. Cela est réalisé par la modélisation 
conceptuelle qui consiste à abstraire la spécification conceptuelle 
du SI, le schéma conceptuel [16] de l'analyse des faits et évé- 
nements pertinents de la réalité observée et pour lesquels la 
communauté des utilisateurs du SI a besoin d'être informée. Cette 
spécification se concentre sur « ce que doit faire » le SI, c'est-à-dire 
sur sa fonctionnalité. Elle sert de prescription pour le dévelop- 
pement du système. 


La modélisation conceptuelle a permis de comprendre la séman- 
tique de l'information, son sens par relation avec les faits obser- 
vables de l'univers du discours, ce qui est important. Les 
recherches et pratiques associées à la modélisation conceptuelle 
ont aussi permis le développement de nombreux modèles 
conceptuels assurant la représentation de différents aspects perti- 
nents de la réalité ; ces modèles ont été en quelque sorte, synthé- 
tisés dans les notations d'UML. 


Mais en revanche, l'expérience montre que la modélisation 
conceptuelle ne garantit pas que le système finalement délivré 
répond aux attentes de la communauté de son usage. En fait, un 
nombre important d'études sur le terrain [Standish95, ESI96, 
Meta03] montrent que les échecs de la mise en œuvre et de l’utili- 


2. De la modélisation 
conceptuelle à l'ingénierie 
des exigences 


2.1 Conceptualisation et cycle 
de développement d'un SI 


Toutes les activités d'ingénierie quelles qu'elles soient, ont pour 
objectif la réalisation d'un produit. Le génie civil vise par exemple, 
à construire des ponts, l'ingénierie automobile fabrique des 
voitures etc. L'ingénierie des SI a pour objectif la construction de 
produits que sont les systèmes d'information. Le produit Sl, 
comme les ponts et les automobiles peuvent se décrire à différents 
niveaux de détail et d'abstraction. On en reconnaît deux principaux 
en ingénierie des SI : le produit conceptuel et le produit réalisé. On 
admet en effet universellement, que l’ensemble des activités 
d'ingénierie conduisant au produit SI s'organise en deux groupes 


sation des systèmes d'information sont majoritairement impu- 
tables à une mauvaise compréhension des besoins auxquels ces 
systèmes tentent de répondre. Par ailleurs, il a été prouvé que les 


(figure 1) : 
— activités de conceptualisation ; 
— activités de transformation. 


efforts requis pour corriger les erreurs d'un document d'exigences 
mal et/ou incomplètement formulé sont très importants [29]. 


Afin de corriger cette situation, il est nécessaire de définir des 
méthodes, des techniques et des outils pour élucider, spécifier, 
valider et négocier les exigences imposées aux SI par les besoins 
de ses usagers, de manière systématique. La communauté de 
l'Ingénierie des Exigences (IE) s'est développée pour répondre à ce 
challenge. 


Les premières visent à représenter certaines parties d'intérêt de 
la réalité par des structures d'information et des règles de 
comportement afin d'obtenir une description conceptuelle de ce 
que le SI sera capable de faire. Elles aboutissent au produit 
conceptuel. Les secondes sont des transformations successives de 
la représentation conceptuelle aboutissant à un système en fonc- 
tionnement. Elles conduisent au produit final, réalisé qui prend la 
forme d'un ensemble de logiciels. Il est important de noter que 
cette classification des activités de production d'un SI, aujourd'hui 
admise par tous, repose sur une analyse de leur nature profonde : 
les activités de conceptualisation sont de nature abstraite et donc 
difficiles à automatiser; elles sont aujourd'hui majoritairement 
conduites par les hommes. Au contraire, les activités de transfor- 
mation se systématisent et s’automatisent. Les approches IDM 
(Ingénierie dirigée par les modèles) sont l'expression la plus 
récente de cette recherche d'automatisation. Dans ce paragraphe, 
l'accent est mis sur le produit conceptuel et sur les activités de sa 
production. 


Nota : exigence et besoin sont les deux faces de la même pièce : le besoin vient des 
parties prenantes du projet SI ; les exigences sont les contraintes imposées au système 
pour garantir la satisfaction du besoin. 


La position centrale de l'IE est que tout SI a un propos que le 
contexte organisationnel lui assigne. Comprendre ce propos est 
une condition nécessaire pour développer un système d'infor- 
mation objectivé, en phase avec les attentes et besoins de la 
communauté de ses usagers. Cette observation suggère qu'il faille 
aller au-delà de la modélisation conceptuelle et étendre la modéli- 
sation du « qu'est-ce que le système doit faire » à « pourquoi le 
système doit-il le faire ». La question du « pourquoi » trouve sa 
réponse dans l'étude des objectifs et buts de l’organisation et de 
leur impact sur les exigences du SI. Elle est au cœur de l'ingénierie 
des exigences et centrale dans cet article. Cette attitude devrait 
permettre dans le futur, de développer des systèmes plus adaptés 
à leur usage et a déjà prouvé qu'elle permettait de le faire. 


L'article part des acquis de la modélisation conceptuelle et argu- 
mente en faveur de son extension par la modélisation du contexte 
intentionnel du SI à développer (parfois qualifié de système To-Be) 
au moyen de modèles de buts. Il présente le concept de but, 
montre comment on peut élaborer un modèle de buts et comment 
conduire des raisonnements permettant d'aboutir à la conceptuali- 
sation de SI objectivés, c'est-à-dire répondant au propos que 
l'organisation leur assigne. Le développement des idées s'appuie 
sur un exemple de réservations de chambres d'hôtels. 


Conception 


Correction RD 


INGÉNIERIE DU SYSTEME 


Plus précisément, l'article est structuré comme suit. Le 
paragraphe 2 justifie l'extension de la modélisation conceptuelle, 
introduit l'ingénierie des exigences et fait un bref état de l’art du 


Figure 1 - Organisation du cycle de développement d'un SI 
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Le produit conceptuel ou schéma conceptuel est une représen- 
tation d’une certaine partie de la réalité, « l'Univers du Discours ». 
Sa production est donc le résultat d’un travail de modélisation 
conceptuelle qui s'appuie sur des modèles, les modèles 
conceptuels. Un modèle propose un ensemble de concepts et de 
règles pour les utiliser qui indiquent au modeleur les entités de la 
réalité sur lesquelles l'effort de représentation doit être concentré. 
Le modèle E/R propose par exemple, les trois concepts d'entité 
type, de relation type et d'attribut comme étant nécessaires et suf- 
fisants pour représenter toute partie du réel par une structure de 
données. Durant ces 25 dernières années, de très nombreux 
modèles conceptuels ont vu le jour, chacun cherchant à proposer 
un jeu de concepts qui permette une représentation plus fidèle de 
la réalité que ses prédécesseurs. On peut schématiquement retenir 
trois classes de modèles [60] : 


eles modèles centrés sur la représentation des structures 
d'entités de la réalité ou modèles de données. Les modèles 
ER et relationnel en sont des exemples ; 


e les modèles fonctionnels poussant à « voir » la réalité comme 
un processus de transformation de l'information. Les 
modèles dits d'analyse structurée en sont des exemples ; 


eles modèles de comportement mettent le concept d'évé- 
nement au centre de la modélisation et poussent à une vision 
dynamique, en mouvement de la réalité. Les modèles 
Remora et les graphes de Harel en sont des exemples. 


On peut voir l'ensemble des notations proposées par le standard 
UML comme étant le résultat d'un effort de synthèse et d'unifi- 
cation des multiples modèles qui ont vu le jour au cours des deux 
décennies passées. La question posée dans cet article est de savoir 
si ce sont finalement ceux dont on a besoin ou si ceux dontona le 
plus besoin sont absents du standard. 


Dans l'ingénierie traditionnelle et les méthodes d'analyse 
comme MERISE, c'est au cours de l'étape de conceptualisation que 
le cahier des charges est pris en compte pour configurer la 
solution conceptuelle matérialisée dans le schéma conceptuel. Il 
est à noter que l'objectif est de décrire ce que le système doit faire, 
c'est-à-dire ses fonctionnalités. Comme le montre la figure 1 
l'ingénierie du besoin fondée sur la modélisation conceptuelle est 
centrée sur la question du « quoi » à laquelle on répond par le 
cycle <acquisition, abstraction, validation>. La tâche d'acquisition 
de connaissance de domaine et des besoins s'appuie sur un cahier 
des charges et des interviews. Elle permet d'abstraire de la 
connaissance acquise, la spécification des fonctionnalités 
attendues du système. Le schéma conceptuel résultant sert de sup- 
port à la validation des besoins par des techniques telles que le 
maquettage et le prototypage. 


2.2 Limites de la modélisation 
conceptuelle 


Le centrage sans doute trop exclusif de la modélisation 
conceptuelle sur le «quoi» inhibe les vraies questions du 
« pourquoi » et aboutit à des choix fonctionnels d'un système qui 
se révèle à l'usage, inadapté aux réelles attentes de ses usagers. 
Le schéma conceptuel est l'expression d'une solution fonctionnelle 
et non celles des exigences à l'égard du système. Il est l'énoncé 
d'une solution alors que le problème n'a pas été formulé correc- 
tement. L'absence d'une expression des exigences en tant que 
telle, rend difficile leur validation par les différentes et nombreuses 
parties prenantes concernées. En outre, la pratique du cycle précé- 
dent repose sur des hypothèses (le plus souvent implicites) qui ne 
semblent plus du tout valides aujourd'hui. 


Les fonctionnalités d’un système sont stables, elles n'évoluent 
que peu dans le temps. En conséquence, le schéma conceptuel 
d'un système est lui aussi stable. 


Les besoins relatifs à un système sont donnés au départ. Les uti- 
lisateurs expriment leurs besoins dans un cahier des charges, le 


problème est donc de construire le système qui répond à ce cahier 
des charges ; ce sont les analystes (la maîtrise d'œuvre) qui sont 
en charge de ce travail. 


La validation des besoins peut se faire en référence aux fonc- 
tionnalités du système. En d'autres termes, le schéma conceptuel 
est le support privilégié pour communiquer, négocier et aboutir au 
consensus nécessaire entre les différentes parties impliquées dans 
le développement du système. 


Si dans les années 1980/1990, ces hypothèses étaient valides, 
elles ne le sont plus aujourd'hui. En réponse aux pressions écono- 
miques et à l'émergence constante de nouvelles technologies, les 
organisations changent plus rapidement que par le passé. En 
conséquence, ce que les utilisateurs attendent du système évolue 
bien plus rapidement qu'auparavant. Leurs besoins ne sont donc 
pas stables [24]. On sait même que les besoins évoluent au cours 
du projet[12] [39]. Il devient nécessaire de propager les 
changements sur les exigences. On verra que cela peut être réalisé 
en établissant un lien conceptuel entre les buts et objectifs de 
l'organisation (réponse au « pourquoi»), les besoins qui en 
résultent et les spécifications fonctionnelles du système qui les 
supportent (réponse au « quoi »). 


On sait que le rôle central de l'analyste système a été 
reconsidéré et que la maîtrise d'ouvrage vient contrebalancer le 
rôle de la maîtrise d'œuvre. En fait, il est clair aujourd'hui que 
l'ingénierie des exigences requiert la participation d'un grand 
nombre d'acteurs de l'organisation, chacun apportant sa vision sur 
ce que le système devrait faire [22]. On distingue par exemple, les 
utilisateurs finaux du système - ceux qui utiliseront le système 
pour mener à bien leurs activités au sein de l'organisation - les 
responsables de l'organisation qui ont décidé de la mise en place 
du système, les personnes responsables de la mise en place et de 
la maintenance du système, etc. ; en fait tous ceux pour qui le 
développement du système constitue un enjeu (les stakeholders 
dans la terminologie anglo-saxonne), les parties prenantes en 
français. 


Enfin, la validation des exigences sur la base du schéma 
conceptuel n'est pas satisfaisante. L'expérience l'a montré. On 
peut accepter l'idée que cette validation soit bien plus efficiente si 
elle est basée sur l'expression d'exigences formulées en langue 
naturelle et non sur la spécification abstraite et difficile à 
comprendre des spécifications fonctionnelles du système qui en 
résultent. Cela justifie l'introduction d'un document des exigences 
dans lequel celles-ci peuvent être spécifiées, discutées, négociées 
et validées. 


Toutes ces observations et remarques militent pour une révision 
de la pratique de l'ingénierie des exigences comme partie de la 
modélisation conceptuelle; en fait elles suggèrent d'une part, 
l'introduction d'un document des exigences et d'autre part, la 
révision de la manière de conduire l'ingénierie des exigences et la 
production du document des exigences qui en résulte. 


2.3 Chiffres motivant le changement 
d'attitude 


L'impact critique de l'analyse des exigences sur la qualité du 
logiciel a été reconnu de longue date et à maintes reprises. Dans 
l'une des premières études empiriques sur le sujet, Bell et Thayer 
relevaient que des exigences inadéquates, incomplètes, 
inconsistantes ou ambiguës étaient monnaie courante dans les 
projets analysés, et cause majeure de la piètre qualité des logiciels 
développés. Ils concluaient que « les exigences n'apparaissent pas 
de manière naturelle et spontanée ; elles doivent au contraire être 
découvertes, élaborées avec soin, et constamment revues » [5]. 
Dans son article célèbre sur la nature et les accidents du génie 
logiciel, Fred Brooks affirme, sur base de sa longue expérience de 
développement de logiciels complexes, que « la tâche la plus diffi- 
cile, dans la construction d'un système logiciel, consiste à décider 
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ce qu'il faut exactement construire, par élucidation et affinement 
itératifs d'exigences » [9]. Dans son étude des erreurs du pro- 
gramme Voyager et Galileo de la NASA, Lutz [40] rapporte que la 
principale cause vient des erreurs d'expression de besoins fonc- 
tionnels et d'interface. 


Des enquêtes plus récentes en Europe et aux États-Unis ont 
confirmé le problème à une plus grande échelle. Une enquête 
menée auprès de 800 projets conduits dans 350 compagnies amé- 
ricaines par le Standish Group [63] et présentée dans deux rap- 
ports, intitulés Chaos et Unfinished Voyages, a révélé que 31 % 
des projets sont annulés avant même d'être terminés. En 1995, 
cela a coûté 81 milliards de dollars aux compagnies américaines. 
Ce même rapport montre que 50 % d'entre eux n'avaient que par- 
tiellement réussi dans le sens où ils avaient nécessité des budgets 
et des délais très fortement majorés. La mauvaise qualité des 
documents de besoins constitue 47 % des causes d'échecs citées. 
Comme l'indique la figure 2, ce pourcentage est distribué de la 
façon suivante : 


- manque de participation des utilisateurs (13 %) ; 
— besoins mal exprimés (ou incomplets) (12 %) ; 
— besoins changés entre le début et la fin du projet (11 %) ; 


— besoins qui manquent de réalisme (6 %), et objectifs peu clairs 
(5 %). 


De plus, parmi les projets menés à terme, près de 67 % des 
coûts de maintenance résultent de l'incomplétude des documents 
des besoins : « La plupart des efforts de maintenance consistent à 
fournir des fonctionnalités nécessaires mais manquantes » [41]. 


En Europe, une enquête de grande envergure auprès de 3 800 
organisations dans 17 pays différents [20] a conclu dans le même 
sens : les principaux problèmes sont liés à la spécification des exi- 
gences (> 50 % des réponses). 


60 % 
50 % 
ox EE 
6% 
30 % 11% 
53 % 


Le rapport du Standish Group est régulièrement actualisé et les 
résultats de 2010 montrent une amélioration sensible des cas de 
succès. Cependant, les causes d'échec restent liées dans les 
mêmes proportions que précédemment au manque de qualité du 
document d'exigences ; le rapport récent du groupe Meta [42] 
montre que 60% des cas d'échecs sont imputables, soit au 
manque de qualité du document d'exigences, soit à l'inaptitude 
des processus d'ingénierie à prendre en compte leur évolution. 


Améliorer la qualité du document des exigences et la pratique 
de l'ingénierie des exigences sont donc des objectifs primordiaux. 
Ces objectifs ne sont pas faciles à atteindre, au vu du large spectre 
de considérations à couvrir, de la multitude de processus et pro- 
duits concernés, de la multitude d'acteurs à impliquer, et de la 
variété d’écueils à éviter. L'ingénierie des exigences est une disci- 
pline aux confins du génie logiciel et de l'ingénierie des systèmes, 
qui vise à offrir des modèles, méthodes et outils pour développer 
et faire évoluer des documents d’exigences de qualité. Cet article 
se propose de donner un aperçu des développements récents dans 
cette discipline relativement jeune et d'en approfondir certains. 


2.4 Paradigme sous-jacent à l'IE 


La position adoptée par l'ingénierie des exigences est qu'il faut 
non seulement comprendre ce que le système doit faire {le 
« quoi ») mais aussi pourquoi il doit le faire (« pourquoi »). L'ingé- 
nierie des exigences va donc au-delà de la modélisation 
conceptuelle centrée sur le « quoi» pour mettre l'accent sur le 
« pourquoi ». La plus ancienne définition de l'IE contient déjà cette 
position. Dans leur article prémonitoire, Ross et Schoman 
écrivent : « Requirements definition is a careful assessment of the 
needs that a system is to fulfil. It must say why a system is nee- 
ded, based on current and foreseen conditions, which may be 
internal operations or external forces. It must say what system 
features will serve and satisfy this context. And it must say how 
the system is to be constructed » [61]. 


L'ingénierie des exigences élargit l'approche classique où l’on 
cherche à comprendre ce qui doit être réalisé par le système en 
essayant de comprendre le « pourquoi» du système, sa raison 
d'être. L'expression du « pourquoi » est faite en termes de buts 
organisationnels et de leur impact sur le système d'information de 
l'organisation. En d'autres termes, l'IE par du principe qu'un sys- 
tème d'information a un propos au sein de l'organisation et que 
celui-ci est déterminant des exigences imposées à son dévelop- 
pement. L'IE vise à aider à la fois à la conceptualisation du sys- 
tème et du propos qui lui est associé. Ce paradigme sous-jacent à 
l'IE a deux implications : 


la découverte et la validation des exiaences d'un svstème 
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our représenter les systèmes d'information, plusieurs types de modèles 

{ou modèles de produits) sont élaborés. La complexité d’un système 
d'information est telle qu'il est nécessaire de combiner plusieurs points de vue 
avec différents niveaux d’abstraction. On distingue classiquement les points de 
vue fonctionnel, dynamique et ontologique et les niveaux conceptuel, organi- 
sationnel, logique et physique. Nous nous intéressons au cas où le projet 
logiciel à conduire est intégré dans un système d'information particulier. 


Pour décrire les différents modèles de produits, nous disposons depuis plu- 
sieurs années du langage de modélisation UML. Dans la version 2.0, ce 
langage propose 13 types de modèles différents. Cette richesse de représenta- 
tion a pour corollaire une difficulté de mise en œuvre: quel diagramme 
choisir ? Comment utiliser les différents éléments de modélisation associés en 
fonction du point de vue et du niveau d'abstraction ? Quel objectif poursuit-on 
en utilisant UML : mode « esquisse » pour communiquer certains aspects du 
système, ou mode « plan » qui permet de préparer la génération du code ? 
Quoi qu'il en soit, le but de cet effort de modélisation est d'améliorer la qualité 
du logiciel produit en améliorant la qualité de son mode de production. 


Les normes de la famille ISO 9000 : 2000 publiées le 15 décembre 2000 sont 
la référence internationale en assurance qualité. Pour faciliter leur application, 
des normes outils sont proposées, dont la norme NFISO/CEI 12207. Ces 
normes préconisent une approche processus. Un « processus » y est défini 
comme un « ensemble d'activités corrélées ou interactives qui transforment 
des éléments d'entrée en éléments de sortie ». Les éléments de sortie sont, 
dans la plupart des cas, des modèles de produits. Nous choisissons d'utiliser 
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UML pour les exprimer. Nous montrons comment cette norme applique les 
principes de base de l'assurance qualité, et comment la mettre en œuvre en 


utilisant les outils de modélisation d'UML. 


La mise en œuvre avec le langage UML est très souvent associée à deux 
modèles de processus : RUP (Rational Unified Process) et 2TUP (2 Tracks 
Unified Process), recensant les meilleures pratiques de développement orienté 
objet. Ce sont des processus génériques, ils proposent une trame commune à 
adapter en fonction du projet traité. Nous montrons qu'ils correspondent à une 


mise en œuvre particulière de la norme ISO/CEI 12207. 


1. Norme NF ISO/CEI 12207 


La norme ISO/CEI 12207 propose un cadre de référence qui dis- 
tingue plusieurs processus regroupés par type. Chaque processus 
est décomposé en activités, les activités sont elles-mêmes 
décomposées en tâches. La norme est présentée comme une col- 
lection d'articles numérotés. Un article numéroté a.b correspond à 
un processus, a.b.c à une activité et a.b.c.d à une tâche. Cette 
norme a été rédigée à l'attention des acquéreurs de systèmes, de 
logiciels et de prestations logicielles, ainsi que pour les fournis- 
seurs, les développeurs, les personnes chargées de l'exploitation 
et de la maintenance. 


Nota : les textes en italique sont des citations in extenso de la norme. 


1.1 Différents types de processus 


Cette norme distingue les processus de base, les processus de 
support et les processus organisationnels. Un panorama des pro- 
cessus considérés par la norme est fourni dans le tableau 1. 


Le processus de documentation (6.1) et les processus organisa- 
tionnels (7.x) sont mis en œuvre par tous les autres processus. Ces 
derniers sont utilisés au niveau de la direction pour établir la struc- 
ture associée à chaque projet et l'améliorer en permanence. 


Le processus d'acquisition (5.1) définit les activités de l’acqué- 
reur. Il commence par /a description d'un concept ou d’un besoin 
d'acquérir, de développer ou d'améliorer un système, un logiciel, 
ou une prestation logicielle. | consiste essentiellement à gérer un 
appel d'offres et le cas échéant le contrat associé. Bien que cette 
norme ne soit pas adaptée au cas des logiciels sur étagère, elle 
permet de conduire un projet qui envisage cette possibilité. La 
tâche 5.1.1.6 de l'activité d'initialisation propose à l'acquéreur 
d'examiner différentes options d'acquisition du système : a) achat 
d'un logiciel sur étagère qui répond aux exigences, b) développe- 
ment du logiciel en interne, c) développement en externe par 
contrat, e) amélioration d'un logiciel existant ou d) toute 
combinaison des options a, b et c. 


Le processus de fourniture (5.2) définit les activités du fournis- 
seur. || peut être initialisé soit par la décision de préparer une pro- 
position de réponse à un appel d'offres, soit par la signature d’un 
contrat avec l'acquéreur. 


Les processus de base (5.x) ne sont pas indépendants les uns 
des autres : ils font, tous, appel au processus de développement 
(5.3). Nous ne considérerons pas dans cet article les processus de 
maintenance (5.5) et d'exploitation (5.4). 


Les différentes activités du processus de développement (5.3) 
concernent, soit le système d'information support, soit le logiciel à 
produire. On y distingue différents niveaux d'étude : compréhen- 
sion du problème sous le terme analyse des exigences, élabora- 
tion de solution sous le terme conception. Le tableau 2 décrit 
l'ensemble des activités du processus de développement. On y dis- 
tingue les activités qui relèvent du niveau système et celles qui 
relèvent du niveau logiciel. 


Tableau 1 - Panorama des processus de la norme 
NF ISO/CEI 12207 
: Nombre 
Type Processus Numéro DSarbre de 
norme | d'activités ” 
tâches 
Acquisition 5,1 5 23 
Processus Fourniture 5,2 7 24 
de base 
5 processus, Développement 5,3 13 55 
“SL Exploitation 5,4 4 9 
Maintenance 55 6 24 
Documentation 6,1 4 
Gestion de 6,2 6 
configuration 
sl 6,3 4 16 
Processus qualité 
de support Vérification 6,4 2 13 
8 processus, - | 
25 activités Validation 6,5 2 10 
70 tâches Revue 6,6 3 8 
conjointe 
Audit 6,7 2 8 
Résolution de 6,8 2 
problème 
Processus Management 7,1 5 12 
organisa- 
tionnels Infrastructure 7,2 3 
4 processus, Amélioration 7,3 3 
14 activités . 
26 tâches Formation 7,4 3 


Quelles que soient les précautions prises au lancement d'un pro- 
jet, la demande du client se précise et évolue au cours du cycle de 
vie du logiciel. Il faut donc aussi définir le processus de gestion 
des changements, ce que permet de faire le processus 6.2 de ges- 
tion de configuration. 


Enfin, le processus 6.8 de résolution de problème permet de 
faire face à toutes les situations non prévues : l'objectif est de four- 
nir un moyen opportun, pertinent et documenté qui permet de 
garantir que tous les problèmes identifiés sont analysés et résolus. 


1.2 Prise en compte des principes 
d'assurance qualité 


L'assurance qualité préconise de se placer systématiquement 
dans une approche contractuelle client-fournisseur, même dans le 
cas d'une étude interne. Cette norme applique ce principe par la 
mise en œuvre des processus d'acquisition (5.1) et de fourniture 
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Tableau 2 - Mise en œuvre de l'approche qualité dans le processus de développement 


Approche qualité 


Plan DO 


Check 


5.3.1 Mise en œuvre 


Niveau système 
d'information 


5.3.2 Analyse des 
exigences du système 


5.3.13 Assistance à 
l'acceptation du logiciel 


5.3.3 Conception de 
l'architecture du système 


5.3.11 Essais et 
qualification du système 


5.3.10 Intégration 
du système 


Niveau logiciel 5.3.4 Analyse des 


exigences du logiciel 


5.3.9 Essais et qualification 
du logiciel 


5.3.5 Conception de 


l'architecture du logiciel du logiciel 


5.3.6 Conception détaillée 


5.3.8 Intégration 
du logiciel 


du logiciel 


5.3.7 Codage et essai 


(5.2). De plus, un processus support lui est dédié (6.3), lequel vise 
à garantir que les processus et les logiciels associés sont confor- 
mes aux exigences requises et respectent les plans préétablis. 


La norme permet aussi d'effectuer les différentes étapes classi- 
quement retenues dans une approche qualité (roue de Deming) : 
définition du mode de travail (PLAN), mise en œuvre du mode de 
travail défini (DO), contrôle (CHECK) et prise en compte des résul- 
tats pour améliorer le processus (ACT). Dans le tableau 2, les acti- 
vités du processus de développement (5.3) sont classées par 
rapport à chacune de ces étapes. 


L'activité 5.3.12 Installation du logiciel n'y est pas représentée : 
elle dépend à la fois du niveau système d'information et du niveau 
logiciel ; c'est une activité qui correspond au DO des préceptes de 
l'assurance qualité. Nous pouvons constater que l'amélioration du 
processus (ACT) est en dehors du champ de la norme 
ISO/CEI 12207. 


1.2.1 Prise en charge du principe de Contrôle 
(CHECK) 


Le contrôle est effectué à plusieurs niveaux : processus et acti- 
vité. Certains processus lui sont dédiés et en tout premier lieu le 
processus 6.3 d'assurance de la qualité, coordonné avec les autres 
processus de supports (6.4, 6.5, 6.6 et 6.7) ayant eux aussi un 
objectif de contrôle. Les processus de support : 6.4 Vérification et 
6.5. Validation, permettent respectivement de vérifier que le logi- 
ciel produit correspond aux exigences et à l'utilisation attendue. 
Les autres processus de support : 6.6 Revue conjointe et 6.7 Audit, 
décrivent le mode de mise en œuvre possible des processus 6.4 et 
6.5. Un audit est toujours réalisé par des personnes qui ne sont 
pas directement responsables des logiciels ou des activités 
qu'elles auditent. 


Les activités du processus de développement : 5.3.9 Essais de 
qualification du logiciel et 5.3.11 Essais de qualification du sys- 
tème, sont centrées sur cet aspect. 


La plupart des autres activités du processus de développement 
comprennent deux étapes : 

— une étape qui décrit l'ensemble des tâches permettant de pro- 
duire de nouvelles modélisations ; 

— une étape de contrôle garantissant la traçabilité et la cohérence 
des modélisations produites avec les activités amont et une éva- 
luation de la faisabilité des activités en aval. 


Par exemple pour l'analyse des exigences du système, la norme 
propose les tâches suivantes : traçabilité des besoins d'acquisition ; 
cohérence avec les besoins d'acquisition ; testabilité ; faisabilité de la 
conception de l'architecture du système; faisabilité de l'exploitation et 
de la maintenance. 


1.2.2 Prise en charge du principe de définition 
du mode de travail (PLAN) 


Les processus proposés doivent être ajustés pour chaque projet 
logiciel. Cette adaptation consiste à choisir des processus, des acti- 
vités ou des tâches. Le processus d'ajustement fait lui aussi partie 
intégrante de la norme, bien qu'il soit décrit dans l’annexe A. Pour 
effectuer cet ajustement, il est nécessaire de considérer les carac- 
téristiques du projet, indépendantes de la méthode de travail utili- 
sée telles que le coût, le délai, le contexte juridique, les exigences 
en termes de sûreté et de sécurité. Cette norme n'impose pas de 
modèle de cycle de vie, ni de méthode particulière. 


Chaque processus comporte une activité permettant de préciser 
le mode de mise en œuvre choisi pour le processus. Cette activité 
est intitulée, soit « initialisation », soit « mise en œuvre ». 


L'activité 5.3.1 Mise en œuvre du processus de développement 
comprend notamment les tâches suivantes : 


5.3.3.1 Si ce n'est pas stipulé au contrat, le développeur doit 
définir et sélectionner un modèle de cycle de vie logiciel approprié 
au domaine d'application, à l'ampleur et à la complexité du projet. 
Les activités et les tâches de ce processus de développement doi- 
vent être sélectionnées et mises en correspondance avec le 
modèle de cycle de vie. 


Note: ces activités et ces tâches peuvent se recouvrir ou agir l’une sur l’autre, et peuvent 
être mises en œuvre de manière itérative ou récursive. 


5.3.1.3 le développeur doit choisir, ajuster et utiliser des nor- 
mes, des méthodes, des outils et des langages de programmation 
(si ce n'est pas spécifié au contrat) qui sont documentés, appro- 
priés et établis par l'organisme pour exécuter les activités du pro- 
cessus de développement et des processus support. 


1.3 Indépendance de la norme vis-à-vis 
des modèles de cycle de vie 


Dès le début des années 1970, des modèles de processus de 
développement du logiciel ont été identifiés et qualifiés de modèle 
de cycle de vie. Un modèle de cycle de vie propose non seulement 
les types de tâche à effectuer, mais aussi leur enchaînement. 


1.3.1 Application de la norme avec le cycle 
en cascade 


Le cycle de vie en cascade permet principalement d'identifier les 
différentes phases de production du logiciel et met en œuvre un 
chaînage avant pour le projet par validation de chaque phase avant 
le passage à la phase suivante. Ce modèle a pour inconvénient 
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Tableau 3 - Le cycle en V avec la norme NF ISO/CEI 12207 


VUE INGÉNIERIE : 5.3 Processus de développement 


5.32 Analyse des exigences du Système 


AN \ 5.3.13 Assistance à 
% 5.3.1 Mise en œuvre 5.3.12 Installation du l'acceptation du Logiciel 
le Logiciel + 
ee ) ‘ 
n 
L z 
+ ‘ 
[ + 4 7 


5.3.11 Essais de 
qualification du Syétème 


Ÿ ‘ 
nN N —- 
533 Conception de [ | é 

l'architecture du Système 5.3.10 Intégration du 
4 Système 
RS > A 
$ + 
= 5.3.9 Essais de 
5.3.4 Analyse dès exigences du Logiciel L nn mmmmmme Be qualification du Logiciel 
$ L 72 
+ 7 
+ 7 
5.3.5 Conception de l'architecture 5.3.6 Conception détaillée 5.3.8 ntégration du 
du Logiciel du Logiciel Fa Logiciel 
Ê LA 
L 7 
EN 
” ‘ 
ge” | 5.3.7 Codage et essai du ) sd 
/ 


d'entraîner de nombreux retours arrière, car il arrive fréquemment 
que des corrections sur les phases précédentes soient nécessaires. 
Ce modèle reste néanmoins valable pour les projets de petite taille 
(phase de codage réduite), dont les besoins sont parfaitement 
connus et stables, et pour lesquels l’équipe projet maîtrise les diffi- 
cultés. La norme NF ISO/CEI 12207 permet d'appliquer ce modèle 
de cycle de vie. || suffit d'effectuer les différentes activités qu'elle 
propose dans l'ordre de numérotation de la norme. 


1.3.2 Application de la norme avec les cycles 
en V et en W 


Le cycle en V concerne des projets dont la taille est plus impor- 
tante car il permet de les fractionner et de réduire le délai de pro- 
duction en décomposant la phase de validation en deux temps: la 
spécification des tests de validation et d'intégration se fait en 
même temps que l'analyse et la conception. Leur exécution est 
réalisée après la phase de codage. La tâche 5.3.3.1 de l'activité 
5.3.3 Conception de l'architecture du système permet de fraction- 
ner le projet en identifiant notamment les différents éléments logi- 
ciels qui seront ensuite étudiés au cours de l’activité 5.3.4 Analyse 
des exigences du logiciel. Le mode de présentation des activités 
tel qu'il est décrit dans la norme, repris dans le tableau 3, induit un 
enchaînement des activités conforme au cycle en V. 


Le cycle en W est, quant à lui, utilisé pour permettre à la maîtrise 
d'ouvrage de préciser ses besoins. Une maquette est réalisée dans 
ce but et le cycle en V est ensuite appliqué. Ce type d'enchaîne- 
ment des tâches est possible avec la norme NF ISO/CEI 12207 puis- 
que la note de la tâche 5.3.3.1 précise que les activités et les tâches 
peuvent être mises en œuvre de manière itérative ou récursive. 


1.3.3 Application de la norme avec RUP et 2TUP 


Les autres modèles de cycle de vie (incrémental, itératif et en 
spirale) ne sont pas considérés car ils sont intégrés dans les modè- 
les de cycle de vie utilisés avec l'approche objet, et donc avec la 
notation UML. 


La mise en œuvre avec le langage UML est très souvent associée 
à deux processus RUP (Rational Unified Process) et 2TUP (2 Tracks 
Unified Process) recensant les meilleures pratiques de développe- 
ment orienté objet. Ce sont des processus génériques, ils définissent 
une séquence d'étapes en partie ordonnée permettant de construire 
ou d'améliorer un système logiciel. Comme leurs auteurs 
eux-mêmes l'indiquent, ces processus constituent une trame com- 
mune. Ils doivent être adaptés au projet considéré. Ces deux pro- 
cessus génériques proposent un développement par itérations, 
piloté par les risques et par les cas d'utilisation. Ils sont adaptés à 
la prise en compte des changements continuels imposés aux sys- 
tèmes d'information et donc aux projets de construction de systè- 
mes logiciel. 


Le processus RUP est conforme à la norme ISO/CEI 12207 : sa 
description et son adaptation au projet réel correspondent à la mise 
en œuvre de l'activité 5.3.1. Ce processus (cf. tableau 4) comporte 
deux dimensions. L'axe horizontal qui représente le temps 
s'exprime en termes de phases (inception ou étude d'opportunité, 
élaboration, construction, transition) et d'itérations. L'axe vertical 
détaille les différents types de tâches à mettre en œuvre pour cha- 
que itération (modélisation métier, besoins, analyse et conception, 
implémentation, tests, déploiement). L'intensité de chaque type de 
tâche varie pour chaque type de phase. Par exemple, l'activité de 
type implémentation est principalement mise en œuvre à la phase 
de construction. 
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Tableau 4 - Différentes étapes dans RUP 


PHASES 


Inception ou h 
2 , _. Élaboration Construction Transition 
Étude d'opportunité 


Modélisation métier D COR NS 


Gestion des exigences D OR nr 


Analyse et conception 


Implémentation 


Es a LS AA T | 
Déploiement er” \ 


Gestion de configuration SD 


et des changements le. 
Gestion de projet DO. CO 


Itération(s) Iter. Iter. Iter. Iter. Iter. Iter. Iter. 
préliminaire(s) #1 #2 zn £n+1 £n+2 £m 4 m+1 
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Les besoins industriels liés à l’utilisation d'un processus de développe- 

ment à base de modèles nécessitent la modélisation des propriétés des 
langages de programmation. L'application de ces propriétés sur des dia- 
grammes d'activité/classes permet de générer des codes des composants 
logiciels. L'architecture de processus incrémental à base de modèles proposée 
dans ce dossier est destinée aux experts d'un domaine pour la mise en place 
d'un atelier métier. 


La sémantique dans les modèles est indispensable aux analystes/concep- 
teurs qui souhaitent contrôler et donc mieux maîtriser le passage des modèles 
de conception aux composants logiciels. 


Quid de l'approche sémantique des modèles dans un milieu industriel 
confronté aux systèmes critiques ? 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie 


est strictement interdite. — © Editions T.I. H 3 880 - ! 


39 


Référence Internet 


H3880 


MODÉLISATION EN UML/OCL DES LANGAGES DE PROGRAMMATION : VERS UN PROCESSUS IDM INCRÉMENTAL 


Principaux sigles 


ATL Atlas Transformation Language 
CIM Computation Independent Model 
DSL Domain Specific Language 

IDM Ingénierie Dirigée par les Modèles 
MDA Model Driven Architecture 

MDE Model Driven Engineering 

OMG Object Management Group 

OCL Object Constraint Language 

PIM Platform Independent Model 
PSM Platform Specific Model 

OVT Query View Transformation 
SysML Contraction de Système et UML 
SOL Structured Query Language 

UML Unified Modeling Language 

XMI XML Metadata Interchange 


1. Besoins industriels 
et processus 
de développement 


Utiliser l'approche MDA [6] (en fait l'approche MDE préconisée 
par l'OMG) dans l'industrie est un challenge certain. À ce jour, des 
tentatives plus ou moins réussies ont eu lieu, mais nous ne 
sommes pas encore au bout du tunnel, qu'en est-il ? 


Nous présentons dans ce dossier une méthode systématique et 
pragmatique de modélisation de la sémantique des langages de 
programmation fondée sur la description en UML et OCL et de son 
application au sein d’un processus IDM où les modèles sont au 
centre des développements des logiciels. Cette approche se fonde 
sur la précision mathématique de la sémantique dénotationnelle 
de même que sur l'accessibilité et le rôle prépondérant des défi- 
nitions en UML/OCL pour répondre à deux grandes questions : 


(1) Comment communiquer aux analystes/concepteurs une défi- 
nition précise d'un langage de modélisation et d'un langage de 
programmation tout en restant accessible ? 

(2) Comment intégrer de la sémantique dans les modèles d’un 
processus IDM de manière cohérente et uniforme avec une 
démarche UML ? 


Dans le contexte d'un processus IDM où précisément ils sont au 
centre du développement, les modèles permettent d'appuyer le 
développement logiciel, en particulier lors de l'activité de géné- 
ration de code (éventuellement spécifiques à des domaines, ou 
DSL) tout en donnant les moyens aux analystes/concepteurs de 
contrôler et de vérifier à chaque phase essentielle d'un processus 
de développement son bon déroulement, et de s'assurer de la 
cohérence entre les modèles à chaque niveau de modélisation. 
Nous illustrons cette approche en prenant comme exemple de 
modèle de conception le diagramme d'activité UML décrivant le 
comportement d'une méthode d'une classe. 


1.1 Langage de modélisation UML 


1.1.1 Démarche de modélisation 


UML est un langage de modélisation graphique initialement 
conçu pour représenter, spécifier, concevoir et documenter les 
artefacts de systèmes logiciel. Adopté par l'Object Management 
Group (OMG) en tant que standard, il est devenu une référence 
incontournable dans le domaine du génie logiciel. 


Le langage de modélisation UML permet de modéliser les exi- 
gences des applications à développer à l’aide de différents types 
de diagrammes, chacun représentant graphiquement, sans séman- 
tique bien définie, un point de vue particulier de l'application. Une 
chaîne complète d'une démarche de modélisation en UML peut 
guider les analystes/concepteurs tout au long du processus de 
modélisation, depuis l'expression des besoins d'une application 
jusqu'à la réalisation des codes des composants logiciels, en 
passant par l'identification des besoins, par la spécification des 
fonctionnalités et par les phases d'analyse et de conception logi- 
cielle. La figure 1 schématise cette démarche, en s'appuyant sur 
les principaux diagrammes d'UML. 


Cette figure montre très schématiquement qu'il s'agit préala- 
blement d'identifier les besoins des utilisateurs de l'application à 
développer et d'en spécifier les fonctionnalités attendues. L'identi- 
fication et la représentation des besoins se font à l’aide de dia- 
grammes de cas d'utilisation qui s'apparentent à une analyse 
fonctionnelle classique. Suit alors une spécification détaillée des 
besoins qui peut se faire sous la forme de diagrammes de 
séquence système. Une maquette de l'application peut alors être 
initiée pour en montrer un aperçu et avoir un premier retour des 
utilisateurs. 


1.1.2 Phases d'analyse et de conception 


La phase d'analyse est centrée sur l'élaboration du diagramme 
de classes. Une analyse du domaine peut être réalisée afin d'iden- 
tifier et de définir les classes et les liens entre elles, l'ensemble 
représentant les aspects métier du domaine de l'application. Le 
diagramme de classes participantes peut alors se déduire des cas 
d'utilisation, du modèle du domaine et de la maquette. Il a pour 
rôle d'assurer la transition entre ces diagrammes et la phase de 
conception logicielle modélisant les interactions et les classes. 
Cette phase d'analyse doit tenir compte de la maquette dont la 
modélisation devrait être réalisée lors de la spécification des fonc- 
tionnalités de manière à prendre en compte les interactions entre 
les futurs utilisateurs à l’aide des diagrammes d'activités de navi- 
gation. 


La phase de conception, enfin, est réalisée à l'aide des dia- 
grammes d'interaction issus des diagrammes de séquence sys- 
tème et des diagrammes de classes de conception. Ils serviront à 
l'implantation, en particulier lors de la production des codes des 
composants logiciels qui dépendent des plates-formes et des 
environnements cibles et, selon les cas, des exigences non fonc- 
tionnelles. 


1.1.3 Phase de génération des codes 


Assuré d'une certaine qualité des modèles élaborés à l'aide 
d'environnements de modélisation et en appliquant méthodologi- 
quement les démarches qui sont préconisées, la génération de 
codes a tendance à se limiter de plus en plus en une simple acti- 
vité de transformation de modèles en codes, réalisée plus ou 
moins directement à l’aide d'outils intégrés dans les éditeurs de 
modèles, assimilant ainsi les langages de modélisation à des lan- 
gages de programmation de haut niveau. Cependant cette phase 
d'élaboration des codes qui est réalisée à partir des modèles et 
que l’on souhaiterait être entièrement automatique, reste une 
activité des processus de développement des plus délicates. 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie 


H 3 880 - 2 


est strictement interdite. — © Editions T.I. 


Référence Internet 


H3880 


MODÉLISATION EN UML/OCL DES LANGAGES DE PROGRAMMATION : VERS UN PROCESSUS IDM INCRÉMENTAL 


Acteur [Système] 
î 


À 


Acteur 


Diagramme 
de cas d'utilisation 


Diagrammes 
de séquence système 


À [Ciasse] [Ciasse] [Ciasse] Ciasse] 


jun 


Diagrammes 
d'interaction 


Dialogue] 


Entité 


att : Type —>{contrôle 
t : 
Entité —— operate> ” ait: Type Ÿ_ . 
it: Type Entité Entité 
— F — ï 5 ait: Type ait: Type 
En] | [en DE Canoe Code 
EU Tee BH: Type Spore operate> TS 
ï ait: Type 
Besoins Entité _ L_Sf Entité P 
—_ fan: Type Dialogue}-fContrôle ai: Type V 
Entité att: Type re Entité Entité 
GIE: Type] operate> = anctype] feu: type 
Entité Entité Contrôle N — 
ait: Type att : Type] operat> 
Dialogue / 
ï . tt: Type | / 
Modèle du domaine operate> Ciesse 
e ai: Type ÿ 
Diagramme Dps: Type Entité 
£ E — 
de classes participantes Le an: pe 
L Entité |? [ Entité 
ne ait: Type ait: Type 
p<> : Type] : 
hs Entité 
ait: Type _ 
Op : Type Entre ] let Type 
Classe att: Type Ent __ 
ait: Type 
de CITE = Eed Er ue 
<<pa ©{_att: Type 
Acteur Une Gps: Type 
Diagramme 
cn de classes de conception 
Acteur 
Maquette de l'IHM 
Diagramme d'activité 
Fu de navigation 
IHM Interface homme-machine g 


Figure 1 - Démarche de modélisation UML 


En effet, il s'agit de transformer des artéfacts de modélisation en 
artefacts de programmation. En amont du processus, on manipule 
des artefacts de modélisation, basés sur le concept objet, qui doi- 
vent rester relativement abstraits pour faciliter la communication 
entre les équipes impliquées dans le processus de développement, 
et pour faciliter la réutilisation d'un certain savoir-faire. Dans les 
phases terminales du processus, on manipule des artefacts de 
programmation, très techniques, qui doivent respecter rigoureuse- 
ment les propriétés syntaxiques et sémantiques des langages des 
plates-formes cibles. Certains langages, conçus pour répondre à 
des domaines d'applications bien ciblées comme les DSL par 
exemple, n'intègrent même pas le concept objet pour des raisons 
pragmatiques. Les composants logiciels, de plus, doivent répondre 
à des exigences non fonctionnelles destinées à faciliter les tests 
retraçant les différentes évolutions des artefacts de modélisation 
au cours du processus. Ils doivent pouvoir être facilement mainte- 
nables pour suivre les différentes évolutions exigées par les utilisa- 
teurs. Les codes doivent donc répondre à des critères pouvant 
souvent être contradictoires avec des exigences non fonction- 
nelles, de performances, d'occupation de l'espace mémoire, voire 
le respect de règles de programmation métier spécifiques à 
chaque entreprise. 


Si la modélisation des exigences d'une application reste donc 
l'activité essentielle d'un processus de développement assurant 


l'élaboration des exigences des applications par étapes de 
raffinages successifs, la génération de codes marque une coupure 
dans le processus entre les modèles qui doivent rester abstraits et 
les codes devant respecter les propriétés formelles des langages et 
qui sont soumis à des contraintes liées aux exigences non fonc- 
tionnelles. Comment dans ces conditions est-on sûr, ou peut-on 
être sûr, que les codes produits reflètent bien les intentions des 
concepteurs ? Comment peut-on assurer la cohérence entre les 
modèles et les programmes correspondants, après maintes et 
maintes maintenances correctives et évolutives ? 


1.1.4 Des modèles aux codes via les techniques 
de compilation 


En réponse à ces préoccupations, les travaux présentés dans ce 
document, issus des retours d'expérience de projets de recherche 
menés dans le cadre de collaborations académiques et indus- 
trielles, les journées Neptune (cf. [Doc. H 3 880]) ou plus 
récemment le projet RNTL DOMINO, le TopCased et l’action IDM 
du CNRS (cf. [Doc. H 3 880]), sont centrés sur cette activité de 
génération de code dans les processus IDM. Il s’agit de définir un 
pont « sémantique » entre les activités de modélisation des exi- 
gences et les activités de génération des codes de manière à 
obtenir plus de continuité entre les modèles et les codes des 
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composants logiciels. L'idée est de s'inspirer des techniques des 
langages de programmation qui sont basées sur des approches 
formelles pour en décrire leurs propriétés syntaxiques et séman- 
tiques, et les appliquer au niveau des langages de modélisation, 
en l'occurrence UML, pour en décrire leurs propriétés structurelles 
et pour y rajouter, autant que l'on peut, leurs propriétés séman- 
tiques. Disposant ainsi des technologies basées sur les mêmes 
fondements, au niveau des modèles et au niveau des codes, les 
analystes/concepteurs ont, dès lors, plus de moyens pour vérifier 
que les composants logiciels (modèles et codes) ont bien les quali- 
tés que les applications peuvent exiger de leur part et que les 
intentions des concepteurs sont prises en compte et bien interpré- 
tés lors de la génération des codes. 


1.2 Processus IDM 


Tout d'abord il faut noter que L'IDM est la traduction française 
du concept MDE. Dans ce document nous nous focalisons sur 
l'approche (processus) dite MDA (à savoir, l'approche MDE préco- 
nisée par l'OMG). 


MDA (Model Driven Architecture) est une approche métho- 
dologique conçue pour accompagner les équipes de dévelop- 
pement de la spécification des besoins jusqu'au code, en 
proposant des transformations successives de modèles (dans 
le même langage ou d'un langage donné vers un autre). 


Maintenant adopté par l'Object Management Group en tant que 
standard, le MDA, huit ans après sa naissance !, est devenu une 
référence incontournable dans le domaine du génie logiciel. 


En quoi consiste une telle approche (processus) ? 
L'approche peut être décrite de manière simplifiée comme suit : 


- réalisation d'un modèle d’exigences : le CIM ; 

— transformation du CIM en un modèle métier : le PIM ; 

- transformation du PIM en un modèle spécifique plate-forme : 
le PSM, à noter qu'un PIM peut donner lieu à plusieurs PSM, à par- 
tir duquel est réalisée la génération de code. 


Pour réaliser les transformations automatiques (à noter qu'il 
existe bien sûr des transformations manuelles et semi-automa- 
tiques), nous devons disposer des différents métamodèles (SysML, 
UML...), d'un langage permettant d'écrire les transformations (ATL, 
OVT...) et enfin d'un outil permettant de les exécuter (par exemple, 
ATL). Le tout doit être intégré dans un outil de modélisation afin 
de garantir la cohérence et l'efficacité de l'ensemble. 


1.3 Besoins industriels 


Un nombre important de questions est soulevé lors du choix et 
la customisation d'un atelier IDM, par exemple: Quels 
outils/méthodes utiliser ?, Les outils/méthodes du commerce 
sont-ils performants ?, … 


Les réponses ne sont pas immédiates et une solution générique 
semble à coup sûr utopique, une seule certitude, dans tous les cas 
nous devons tenir compte des besoins et contraintes de l'entreprise. 


Par ailleurs, l'approche IDM nous parle de PIM et de transfor- 
mations possibles vers des PSM, que peut-on en dire ? réaliste ou 
utopique ? En fait, cela reste réaliste si on choisit une cible, et réel- 
lement utopique si l'on espère pouvoir générer n PSM à partir d'un 
même PIN sans un fort investissement. 


Ci-après, nous vous proposons les principales étapes de notre 
démarche qui permet de mettre en place l’environnement néces- 
saire au bon déroulement de l'approche IDM. 


1. Cibler le type d'application à traiter (elle doit forcément être 
récurrente sinon l'investissement ne sera jamais rentabilisé), par 
exemple les systèmes d'information. 

2. Choisir le/les « Framework » cible, par exemple, JAVA/J2EE 
avec HIBERNATE, STRUTS... 


3. Définir la méthodologie utilisée (la démarche 
méthodologique : les grandes étapes, les entrées sorties, les 
guides...). 


4. Définir les différentes transformations de modèles souhaitées 
(par exemple, les diagrammes d'activités UML vers du code, 
cf 8 3.2). 

5. Choisir un outil de modélisation. Mais, attention, pas le 
meilleur outil du marché, mais celui qui correspond aux besoins. 
Afin de réaliser ce choix il faut lister les critères clés, puis évaluer 
les outils candidats à partir de ces critères, et enfin faire un choix. 

6. Installer et customiser (et notamment écrire les transfor- 
mations) l'outil de modélisation. 

7. Former les équipes à la méthodologie et aux outils. 

8. Déployer (prévoir un accompagnement/support) sur un ou 
deux projets pilotes. 

9. Ajuster l'atelier en fonction des retours opérationnels. 

10. Mettre en place une équipe support. 

11. Déployer dans l'entreprise. 


Après le choix et le déploiement du/ou des ateliers dans l'entre- 
prise, on constate un gain important en qualité, en performances 
et en productivité (20 % ont été constatés !! mais, attention, uni- 
quement sur la partie liée à l'IDM bien sûr). 


Sur la figure 2, on peut voir la représentation d'un exemple de 
processus mis en place au sein de la société CS Communication et 
Systèmes. Ce processus cible les systèmes d'information, avec 
une technologie JAVA/JEE, Struts, Hibernate... L'outil de modéli- 
sation utilisé est Power-AMC qui a été configuré suivant ce proces- 
sus comprenant onze transformations de modèles permettant 
d'aller progressivement depuis la spécification jusqu'au code et la 
documentation. 


1.4 Vers un processus IDM 
de développement logiciel 
incrémental 


L'activité de génération de codes devient donc elle-même un 
processus IDM incrémental pouvant se décomposer en une pre- 
mière activité de transformation de modèles de conception en 
modèles de programmation et une seconde activité de raffinage de 
modèles de codes jusqu'à l'obtention des codes. 


1.4.1 Modèles de conception et modèles 
de programmation d'un processus IDM 


Les analystes/concepteurs peuvent dès lors vérifier la cohérence 
entre les modèles de conception et les modèles de programmation, 
et si nécessaire agir sur le processus de génération de codes. On 
assure ainsi plus de continuité entre les activités de modélisation des 
exigences et de génération de codes en prolongeant le processus 
IDM jusqu'aux activités de raffinage de codes. La figure 3 montre 
cette architecture de processus où « L » est un langage quelconque 
dont on donne un exemple dans les paragraphes suivants. 


Pour des domaines d'applications ayant des exigences très 
critiques, comme les systèmes embarqués, les environnements de 
collaboration grand public manipulant des données privées, voire 
confidentielles, on voit tout l'intérêt que peut offrir un environ- 
nement de développement et de programmation permettant de 
vérifier la cohérence entre les modèles et les codes et d'effectuer 
des contrôles à chaque étape du processus. Différents domaines 
de recherche ont été abordés au cours de cette étude, en particu- 
lier les processus dirigés par les modèles, les langages de pro- 
grammation, les preuves de programmes. Nous avons 
particulièrement porté notre effort sur l'aspect formel des 
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Les parties en blanc et en vert (en romain) sont générées automatiquement à partir du modèle UML. Les parties roses (en italique) sont codées manuellement. 


Figure 2 - Exemple d'un processus déployé de manière opérationnelle à CS Communication et Systèmes 
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Figure 3 - Architecture d’un processus intégrant un niveau de modélisation des codes 


notations pour décrire les spécifications et les raffiner en UML et 
en OCL de manière à offrir aux analystes/concepteurs un forma- 
lisme le plus homogène possible, tout au long du processus de 
développement, et de leurs différentes activités de maintenances 
correctives et évolutives, et de documentation. 


1.4.2 Rapprochement des technologies 
de traducteurs et des modèles 
On rappelle brièvement qu'un programme a deux représentations : 


— une représentation externe manipulée sous forme textuelle par 
le programmeur ; 
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une représentation interne au niveau du traducteur dont la struc- 
ture est spécifiquement définie par le traducteur en vue des vérifica- 
tions et des transformations qu'il devra appliquer sur le programme. 


Tout traducteur, considéré comme une boîte noire, se définit sa 
propre structure interne, transparente aux programmeurs devant 
se consacrer à l'implémentation des algorithmes tout en s'assurant 
que le programme respecte bien les propriétés de typage des dif- 
férentes instructions du langage, ainsi que leurs propriétés 
comportementales. Tout traducteur se chargera, cependant, de 
vérifier les propriétés du langage à chaque prise en charge d'un 
programme. 

En ce qui concerne la modélisation, le principe est le même. Les 
modèles élaborés par les concepteurs à l'écran correspondent à la 
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représentation externe des modèles. L'éditeur de modèles enre- 
gistre en interne les modèles selon une structure interne, définie à 
un niveau métamodélisation que l'on appelle le Métamodèle. 
Contrairement à la technologie des traducteurs et des grammaires, 
en UML le métamodèle a fait l'objet d'une définition par l'OMG 
permettant ainsi l'échange de modèles entre les éditeurs de 
modèles ; le métamodèle UML devant ainsi un standard de fait. 
Certains éditeurs intègrent des exports pour générer des architec- 
tures de codes, voire des codes complets dans certains cas. 


Cependant, on trouve de plus en plus d'environnements de pro- 
grammation interactifs, pour le langage Java par exemple sur Win- 
dows ou sur Eclipse, suivant et guidant le programmeur à chaque 
modification du programme de manière à le prévenir au plus tôt 
toute erreur qui pourrait apparaître dans le code. En fait, l'étude 
que nous proposons dans ce dossier, s'apparente à ces environ- 
nements de programmation, depuis l’activité de modélisation des 
exigences jusqu'à l’activité de génération des codes, permettant 
ainsi de vérifier la cohérence entre les modèles et les codes. 


1.4.3 Comparaison des différents niveaux 
de modélisation et de métamodélisation 


La figure 4 rappelle la hiérarchie de métamodélisation à quatre 
niveaux définie par l'OMG (Object Management Group). 


La figure 5 donne un exemple d'utilisation de cette architecture 
en quatre couches. 


1.4.4 Le langage OCL, partie intégrante de UML 


On peut trouver de très nombreux documents sur le langage de 
modélisation UML, en particulier la norme officielle de UML 
(cf. [Doc. H 3 880]), un certain nombre de livres sur UML, en 
particulier [7] où l’on trouve une présentation détaillée du langage 


OCL, des cours sur Internet, en particulier [4], et un résumé très 
complet dans le dossier [H 3 238] consacré à l'UML. 


Cependant, ce dossier est très orienté sur le langage de 
contraintes OCL, partie intégrante de UML, qui permet de prendre 
en compte, sous forme de propriétés, les exigences des appli- 
cations à développer qui ne peuvent pas s'exprimer graphi- 
quement à l’aide des diagrammes UML. Le langage de contraintes 
OCL, complément indispensable donc à une représentation 
graphique des modèles, permet des propriétés qui apportent au 
niveau des modèles les précisions exigées par les applications qui 
pourront ensuite être reprises lors de la génération des codes des 
composants logiciels, permettant en particulier la vérification de la 
cohérence entre les modèles de conception et les modèles des 
codes. Basé sur la logique des prédicats du premier ordre, et 
reprenant le typage de UML, le langage OCL peut être d'un abord 
difficile. OCL est un langage fonctionnel, qui comme le langage de 
bases de données relationnel SQL (Structured Query Language), 
permet de naviguer au sein d'un modèle pour vérifier qu'il a bien 
toutes les qualités requises. Les propriétés OCL, appelées inva- 
riants, sont sans effet de bord. Un langage d'actions complète le 
langage OCL, permettant de modéliser les méthodes des opé- 
rations des classes dont les spécifications peuvent être complétées 
par des pré- et post-conditions. 


Les propriétés OCL sont écrites au niveau d'un modèle, et sont 
donc applicables à toute instance du modèle. Cependant, compte 
tenu de l'architecture des différents niveaux de métamodélisation 
préconisée par l'OMG, tel que nous l'avons rappelé précé- 
demment, les propriétés OCL peuvent être définies au niveau 
métamodélisation. Dans ce cas, les (méta-)propriétés OCL s'appli- 
quont sur les métadonnées de tout modèle UML. C'est principa- 
lement à ce niveau que nous utilisons le langage OCL, puisque 
l'objectif de cette étude concerne la modélisation en UML/OCL des 
propriétés des langages de programmation. 
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BNF : Métarègle,.… 
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Figure 4 - Architecture de métamodélisation de l'OMG, composée en quatre couches 
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D:: les grandes entreprises, il est nécessaire d'aller de plus en plus vite 
pour offrir aux utilisateurs les outils dont ils ont un besoin vital. De même, 
la mise en production d'une application développée « entre informaticiens » n’est 
plus concevable : les risques de rejet pur et simple par les utilisateurs de 
l'application produite sont trop importants. Il s’agit de trouver un moyen de 
développer des applications selon une méthodologie permettant de répondre 
à ces besoins cruciaux pour l'entreprise : il faut aller vite (un marché se gagne 
plus facilement quand l’entreprise y est présente rapidement et efficacement) ; 
il faut produire des logiciels correspondant exactement aux besoins des 
utilisateurs ; il faut enfin garantir une réactivité importante face aux évolutions 
des marchés concurrentiels. 
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La remise en cause de la méthode employée pour produire les logiciels de 
l’entreprise est une obligation. Les méthodes « anciennes », trop linéaires et 
souvent « mal » appliquées, qui amènent à produire une documentation volu- 
mineuse, redondante, jamais à jour et que de toutes façons « personne ne lit 
vraiment », ne répondent pas à ces nouveaux besoins. Il est alors tentant 
d'examiner de nouvelles solutions. Comme souvent, celles-ci sont nées de l’autre 
côté de l'Atlantique. Le développement rapide d'applications (Rapid Application 
Development ou RAD) est une réponse possible. Inventée par l'Américain James 
Martin, cette méthode offre des avantages importants : 


— la forte implication des futurs utilisateurs de l'application permet de 
garantir l'adéquation entre les besoins exprimés et le logiciel produit ; 

— la logique économique qu'elle implique interdit le développement de 
fonctionnalités « inutiles » ; 

— l'utilisation judicieuse des outils informatiques disponibles oriente vers la 
production d'une documentation nécessaire et suffisante ; 

— le respect strict de l'enveloppe budgétaire et des délais permet d’avoir une 
vision stratégique efficace. 


Le principe fondamental du RAD est le suivant: il s'agit de fixer, dès 
l'initialisation du projet, une enveloppe temps/argent dans laquelle le projet doit 
impérativement s'inscrire. Le projet étant construit intégralement avec les 
utilisateurs, c'est à eux, avec l’aide d'un animateur RAD, qu'incombe la tâche 
de faire cadrer le projet avec le budget défini. L'ensemble des phases du projet 
est couvert par le RAD et réalisé avec les futurs utilisateurs du système : de la 
phase de conception de la base de données jusqu'à la mise au point des écrans 
et des états produits, par itérations successives de prototypage. Il en résulte alors 
l'obligation de ne développer que des fonctionnalités « utiles », en éliminant les 
développements particuliers n'emportant pas l'adhésion générale. Il est souvent 
demandé par des utilisateurs des versions multiples d’une restitution (qu'elle 
soit imprimable ou consultable à l'écran) : dans le cas d’un projet RAD, on cherche 
à produire une restitution unique, rassemblant l'ensemble des informations et 
permettant d'emporter les suffrages de chacun des participants au projet. 


Le RAD ne permet pas de traiter des projets dont la charge prévisible est trop 
importante (supérieure à trois années/homme). Dans ce cas, un lotissement est 
nécessaire afin de découper le projet en autant de sous-projets compatibles avec 
les exigences de la méthode. Il est en effet extrêmement délicat d'animer des 
réunions RAD mettant en cause un trop grand nombre d'utilisateurs différents 
sur un même projet (les risques de « dérive » des réunions sont alors importants). 


Si le RAD a été d'abord conçu pour mener des projets de type transactionnel 
(permettant à une entreprise d'acquérir de nouvelles données grâce à des 
fonctionnalités de saisie et de mise à jour), d'autres types d'applications peuvent 
également s'inspirer largement de la méthode pour gagner en efficacité. La mise 
en place d’un système informatique décisionnel nécessite la même implication 
importante des utilisateurs afin de garantir l'adéquation exacte du produit livré 
aux besoins à couvrir. 


Les objectifs du RAD sont de trois ordres (figure 1). Ils sont tout 


1. Présentation générale 1.1 Objectifs 
Le RAD est une méthode de travail (concept) permettant aux d'abord liés à la productivité. Le but à atteindre est classiquement 
utilisateurs et aux informaticiens d'aborder ensemble les phases un gain de charge significatif et un raccourcissement du cycle de 
d'un projet pour : développement dans 


respect d'une enveloppe budgétaire 


— décrire le domaine fonctionnel couvert, le travail des (temps/argent), tout en maîtrisant la qualité du produit final. 


utilisateurs et leurs besoins ; 
— élaborer les spécifications et la conception de la future 


La deuxième cible du RAD concerne la qualité. || permet de garantir 
l'adéquation du produit fini aux besoins exprimés par l'utilisateur, 


Fee à Mméliorer le prototybeleten dernier lieu valider le la réduction des erreurs de spécifications et donc le nombre de 
rs ee a p YP ds changements a posteriori, et en dernier lieu, la réduction des coûts 
Progu A de maintenance. 
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Historique 


L'informatique est une industrie lourde dont le chiffre d'affaires 
mondial était de 1 000 milliards de dollars en 1999. Elle cumule 
aujourd'hui les contraintes, telles que la complexité croissante 
des produits, les changements plus fréquents, les temps de déve- 
loppement plus longs, la croissance des coûts de conception ou 
encore l'absorption des ressources par la maintenance applica- 
tive de l'existant. À ce propos, il faut rappeler qu'en 1992, le 
« stock » d'applications maintenues en France s'évaluait à envi- 
ron 1 000 milliards de francs, alors que dans un même temps, le 
portefeuille d'applications en attente était équivalent à trois 
années de développement. 

Aujourd'hui encore, les entreprises consacrent entre 40 et 75 % 
de leurs ressources de développement à la maintenance des 
applications existantes. Parmi ces dernières, les grands projets 
(plus de 60 000 lignes de code) coûtent deux fois leur budget 
initial. 

L'ensemble de ces constats a amené les décideurs à se poser la 
question suivante : « Comment améliorer la productivité et, par 
conséquent, réduire les coûts ? ». Un problème n'arrivant jamais 
seul, le décideur doit également faire face à l’évolution. 


B Évolutions technologiques 


Les évolutions technologiques récentes en informatique 
suivent quatre axes qui aujourd'hui convergent. 


e Performances des calculateurs : la puissance des machines 
double environ tous les 18 mois. 


e Interfaces graphiques: elles sont aujourd'hui matures. La 
priorité n’est plus donnée aux applications mais aux données. En 
effet, Windows, Winword, Excel et toute autre application de 
micro-informatique sont des outils qui permettent de travailler 
des données. Tous ces outils sont — et doivent être — de plus en 
plus transparents par rapport aux informations qu'ils utilisent. 

L'exemple le plus parlant est sans doute COM/COM+ qui 
permet de faire des liaisons et des incorporations d'objets d'un 
outil à l'autre (principe du Drag and Drop). L'objet technique per- 
met également, à partir d'un même document, de changer 
d'application pour traiter ce document. L'environnement ne 
change plus, c'est l'outil utilisé qui change. 

e HTTP/HTML : l'essor du client-serveur léger date de la fin des 
années 1980. Il est bien entendu lié à l'évolution de la micro-infor- 
matique et des réseaux locaux. 


e Objet : l'un des principaux atouts de l'objet est sans nul doute 
la réutilisabilité, aussi bien des données que des traitements, des 
fonctionnalités. || permet l'enrichissement de l'existant et l’utilisa- 
tion de composants (Custom Control) qui sont proposés sur le 
marché comme des boutons 3D, des fenêtres d'impression, etc. 
Tous ces composants sont intégrables facilement, peu chers et 
permettent de proposer des solutions adaptées à l'utilisateur. 


Un projet long est un mauvais projet 


Le retour d'investissement 
doit être immédiat. 


Maîtrise 
des coûts 


Maîtrise 
des délais 


Les utilisateurs disposent 
rapidement de leur outil. 


Maîtrise de 
la Qualité 


Les besoins qui évoluent 
en cours de réalisation 
sont pris en compte. 


Figure 1 - Objectifs du RAD 


Le dernier objectif du RAD est la satisfaction des utilisateurs. Il 
permet, il impose même, une participation active et une motivation 
des utilisateurs. C'est sans nul doute un point majeur dans la mesure 
où une application conçue, réalisée avec les utilisateurs est forcé- 
ment conforme à leurs attentes et ne risque donc pas d'être rejetée. 


1.2 Moyens 


Ce sont essentiellement la communication et l'engagement des 
partenaires dans le projet. Cela semble simpliste mais sans ces 
prérequis, là où une méthode dite standard permettrait d'aboutir 
difficilement avec le risque majeur d’un rejet total du produit, le RAD 
ne peut même pas être envisagé. 


1.3 Caractéristiques 


En premier lieu, le RAD peut être caractérisé de processus 
orchestré. En effet, la pluralité des acteurs ainsi que leurs origines 
(tous ne sont pas informaticiens) font que la coordination est 
primordiale. 


La deuxième caractéristique est que le RAD implique un travail 
de groupe. Des réunions de travail entre utilisateurs et informati- 
ciens sont à organiser périodiquement (fréquence dépendante du 
projet, de la localisation géographique des utilisateurs, etc.), avec 
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P:;: les principaux phénomènes qui révolutionnent l'industrie du logiciel, 
nous constatons que les applications deviennent de plus en plus grosses et 
de plus en plus complexes et que les technologies orientées objets font une per- 
cée irréversible sur le marché, introduisant dans les méthodes de développe- 
ment logiciel une flexibilité nouvelle. Ainsi, les technologies de développement 
du logiciel ont un poids de plus en plus important dans l'économie. Face à la dif- 
ficulté de maîtriser le développement du logiciel, le succès de nombreux projets 
repose sur le respect d’un petit nombre de règles clés : 


— gérer les besoins : les besoins métiers changent tous les jours et leur ges- 
tion formelle est une activité indispensable qui permet de s'assurer que le sys- 
tème final répond bien à ce que les utilisateurs en attendent. Cette gestion doit 
recouvrir la formalisation, la documentation, l’organisation et le suivi des chan- 
gements des besoins ; 

— employer des architectures à base de composants : une des évolutions 
technologiques majeures en matière de développement logiciel est l'avènement 
des composants. Les architectures à base de composants constituent la seule 
réponse à l’évolutivité nécessaire et permanente des systèmes d’information ; 
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— modéliser visuellement l'architecture : il est impossible d'appréhender la 
complexité et de communiquer efficacement à tous les membres d'une équipe 
les aspects d'architecture et de comportement d’un système sans une modélisa- 
tion visuelle et graphique. L’avènement d'un standard tel que UML représente 
une avancée majeure dans ce domaine ; 

— développer de manière itérative : étant donnée la sophistication des systè- 
mes actuels, il n’est plus possible de se contenter de mettre en série les activités 
de définition, de conception, de développement et de test. Les nombreux échecs 
enregistrés récemment dans de grands programmes en sont une preuve évi- 
dente. Une approche itérative fournit une plus grande flexibilité car elle permet 
de prendre en compte rapidement de nouveaux besoins ou des changements 
tactiques, et d'identifier et de résoudre les risques au plus tôt ; 

— vérifier la qualité : du fait du rôle fondamental des systèmes dans la vie de 
l'entreprise, leur qualité doit être irréprochable. Celle-ci n’est pas l'affaire de per- 
sonnes extérieures, mais résulte de l’activité quotidienne de tous les membres 
de l’équipe de développement. La vérification permanente de la qualité (adéqua- 
tion, fiabilité, performance) est essentielle. Elle repose sur trois principes fonda- 
mentaux : tester tôt, tester souvent, tester automatiquement ; 

— gérer les changements : le succès du développement itératif et du dévelop- 
pement parallèle repose sur la capacité à gérer les évolutions et les change- 
ments qui surviendront inévitablement pendant le développement, et à maîtriser 
les activités quotidiennes du développement liées à la multiplicité des interve- 
nants. 


Ces principes doivent constituer la base de toute démarche de développement 
moderne qui repose, en outre, sur l'automatisation des activités. Celle-ci permet 
d'augmenter la productivité des équipes de développement, de garantir le res- 
pect des procédures et de minimiser les risques d'erreurs. 


Parmi les nouveaux concepts logiciels, l'approche composant doit permettre 
de trouver une structure globale, manipulable par des gens dont le métier est de 
composer des structures plutôt que d'inventer des éléments permettant de 
construire des structures. Un système fabriqué avec des objets, par exemple une 
comptabilité, une messagerie, peut comporter de 400 à 1 000 classes, alors 
qu'en le structurant en composants, on peut ramener à 10 ou 20 le nombre de 
briques manipulées. L'objet, au sens traditionnel du terme, évolue vers une 
structure à base de composants et cette problématique se retrouve dans la fabri- 
cation des logiciels, les middlewares, les systèmes de gestion de base de don- 
nées (SGBD), etc. 


Si construire une application est un processus complexe, il n'est pas possible 
de trouver un qualificatif pour l'ingénierie des applications distribuées. Différen- 
tes technologies sont aujourd’hui proposées pour permettre l'accès à des don- 
nées distantes ou l'exécution à distance de programmes. Ces technologies 
reposent sur l'ajout à un système d'exploitation existant d’une couche logicielle 
appelée « middleware », comme par exemple les courtiers d'objets (ORB) ou les 
bus de messages. Les applications sont construites comme une collection de 
composants logiciels indépendants, interconnectés à l'aide de ces 
« middlewares ». Pour mettre en évidence la structure des applications, ces 
assemblages peuvent être décrits à l’aide d’'ADL (Architecture Description Lan- 
guage) qui permettent la mise en œuvre des différents composants de l'appli- 
cation par des langages de programmation différents, et l'intégration de ceux-ci 
à travers différents modèles d'exécution ou de communication reposant sur un 
ou plusieurs middlewares (interaction client/serveur pour les ORB ou modèle 
événement/réaction dans le cas des bus de messages). 


Cet article présente les principaux éléments de la technologie composant, tels 
qu'ils se discutent dans les différents consortiums industriels, c'est-à-dire les 
Java Beans, les Enterprise Java Beans (EJB), les composants OMG (Object 
Management Group) et la vision Microsoft. Finalement, nous discutons des lan- 
gages de description d’architectures (ADL) à travers une présentation synthéti- 
que du projet Olan mené par l’équipe SIRAC (Systèmes informatiques répartis 
pour applications coopératives) de l'Institut national de la recherche en informa- 
tique et automatique (INRIA). 
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Abréviation Définition Abréviation Définition 

ADL Architecture Description Language ILU Inter-Language Unification 

API Application Programming Interface JDBC Java Data Base Connectivity 

Rad Active Server Page JNDI Java Naming and Directory Interface 
Eu base de données JTM Java Transaction Manager 

BDK Beans Development Kit MOF Meta-Object Facility 

EL Bean-Managed Persistence MSMO Microsoft Message Oueuing Services 
CGI Common Gateway Interface MTS Microsoft Transaction Server 

CIDL Component Implementation Description Language OCL Olan Configuration language 

CIF Component Implementation Framework ODMG Object Database Management Group 
CMP Container-Managed Persistence OMG Object Management Group 

COM Component Object Model OMT Object Modeling Technique 

CORBA Common Objet Request Broker Architecture O0L Object Query language 

COTS Commercial On The Shelf ORB Object Request Broker 

DCE Distributed Computing Environment OSD Open Software Description 

DCOM Distributed Component Object Model POA Portable Object Adapter 

DII Dynamic Invocation Interface RMI Remote Method Invocation 

DNA Distributed Network Architecture RPC Remote Procedure Call 

eu Document Type Definition SGBD système de gestion de base de données 
_. Enterprise Application Integration SIRAC systèmes informatiques répartis pour applications 
EJB Enterprise Java Beans coopératives 

GUI Graphic User Interface SSL Secure Sockets Layer 

HTML HyperText Markup Language UML Inified Modeling Language 

HTTP HyperText Transfer Protocol URL Uniform Resource Locator 

IDL Interface Description Language VBScript Visual Basic Script 

IS Internet Information Server XML eXtensible Markup Language 


1. Des objets aux composants 


Les années 1990 ont vu l'explosion de l'utilisation du paradigme 
de l'objet pour la construction de logiciels aussi bien au niveau des 
méthodes de conception (OMT, UML), des langages de programma- 
tion (C++, Java), des interfaces graphiques, des bases de données 
orientées objet (OOL, ODMG) que des systèmes distribués (CORBA). 
Ilest maintenant notoirement reconnu que l'objet est un paradigme 
incontournable pour construire du logiciel évolutif et maintenable. 
Néanmoins, l'objet n'est pas sans défaut et il est de plus en plus 
question de composants comme ceux de Microsoft, les Java Beans, 
les Enterprise Java Beans ou bien les composants CORBA pour ne 
citer que les plus connus. Si les bénéfices de l'utilisation des objets 
sont assez bien caractérisés dans la littérature [1], il faut noter que le 
paradigme composant reste très flou. Il est difficile de placer une 
frontière entre les objets et les composants : un composant n'est-il 
pas tout simplement un objet évolué ? Comment caractériser alors 
ces évolutions ? Ce paragraphe expose l'évolution conduisant les 
objets vers les composants en illustrant quelques apports de ces 
derniers. 


1.1 Des objets … 


Rappelons brièvement quelques concepts clés des objets, à 
savoir l'encapsulation, l'instanciation, le polymorphisme et l'héri- 
tage. Un objet est une boîte noire regroupant des traitements (ou 
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méthodes) agissant sur des données (ou attributs). Les attributs ne 
sont accessibles que par des méthodes (le principe d'encapsula- 
tion). L'instanciation d'un objet est faite à partir d'un moule (souvent 
une classe) définissant la liste des attributs et des méthodes de ses 
instances. L'ensemble des méthodes accessibles depuis l'extérieur 
forme l'interface publique de l'objet. Des objets de classes différen- 
tes peuvent partager une interface commune (polymorphisme). 
L'héritage permet de classifier, spécialiser et étendre les classes et 
les interfaces. 


Ilest important de noter que les concepts précités et les construc- 
tions des langages de programmation favorisent seulement la réuti- 
lisation des moules (classes et interfaces) mais s'occupent rarement 
de la réutilisation des objets. Par exemple, la persistance d'un objet 
doit être prévue dans son implantation. Si on désire ajouter de la 
sécurité sur cet objet, il faut créer une nouvelle implantation qui 
peut réutiliser l'ancienne. Ainsi, on peut étendre les classes, par réu- 
tilisation, durant la conception, mais il est rarement possible d'éten- 
dre un objet à l'exécution. Cela provient tout simplement du fait que 
tous les aspects fonctionnels d'un objet sont codés « en dur » dans 
sa classe : il n'y a pas de séparation des aspects. Par ailleurs, une 
application est constituée d'un ensemble d'objets interconnectés. 
Cependant, peu de langages offrent des constructions sémantiques 
pour exprimer cette notion de composition. Par exemple, si deux 
objets doivent s'autoréférencer, il est nécessaire de prévoir une 
méthode publique affectant un attribut privé dans chacune des deux 
classes. De plus, il est nécessaire d'écrire quelque part dans le logi- 
ciel l'appel à ces deux méthodes d'affectation. Ici, la solution est 
donc une construction technique et non sémantique. Les compo- 
sants ont pour objectif de proposer des solutions à la réutilisation 
des objets. 
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1.2 .… aux composants 


Du point de vue externe, un composant ressemble tout à fait à un 
objet, il est décrit par une ou plusieurs interfaces (figure 1). Par 
contre, du point de vue interne, un composant est constitué d'un ou 
de plusieurs objets. Dans le modèle COM de Microsoft [5][61[7] ou le 
modèle Olan de l'équipe SIRAC/INRIA [8], un composant peut être 
construit par agrégation/composition de plusieurs objets binaires 
préexistants. 


Dans ce type d'environnement, un effort particulier est fait sur la 
propriété de réutilisabilité des composants logiciels. Pour compren- 
dre cette propriété, il peut être utile de faire l'analogie avec des 
composants matériels. Par exemple, selon le niveau de granularité 
choisi, construire un ordinateur peut être une tâche aisée. C’est en 
particulier le cas pour les sociétés d'assemblage qui se contentent 
de mettre ensemble différents composants disponibles sur le mar- 
ché. Il suffit de connaître le principe de fonctionnement de chaque 
composant et la manière dont chacun d'eux peut communiquer 
avec son environnement. Chaque composant peut être considéré 
comme une boîte noire pour laquelle il suffit de connaître les servi- 
ces rendus et quelques règles d'interconnexion. Les constructeurs 
d'application souhaitent aujourd'hui appliquer la même démarche à 
des composants logiciels. La programmation par composition per- 
met de construire une application par assemblage de composants. 
Les composants sont des modules logiciels de natures très diverses 
qu'un constructeur d'application peut composer pour construire 
une application répartie. 


1.3 Middlewares pour composants 


Différents mécanismes sont actuellement utilisés par les appli- 
cations réparties afin de permettre des appels entre objets distants 
en cachant les différents problèmes liés à la distribution. Les cour- 
tiers d'objets (ORB) comme CORBA [H 2 758] ou DCOM sont le plus 
fréquemment utilisés mais d'autres modèles, comme les bus de 
messages [91110], méritent d'être utilisés. 


Les systèmes construits à l’aide d’un ORB (sans logiciel) fournis- 
sent des mécanismes pour l'intégration de modules logiciels hétéro- 
gènes qui peuvent être accédés comme des services locaux par des 
applications distantes. Le but de ces systèmes est de séparer la mise 
en œuvre des composants de leur utilisation à travers des interfaces 
qui sont l'unique information que les programmes connaissent. Un 
des aspects importants de cette approche est la projection du lan- 
gage de définition d'interface (Interface Description Language, IDL) 


Propriétés 
configurables 


synchrone synchrone 


Composant 


fournit 
utilise 


asynchrone asynchrone 


Contraintes 
techniques 


Figure 1 - Modèle générique de composants 
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Connecteur 
synchrone 


Connecteur 
asynchrone 


Structure d'accueil 


Bus logiciel (middleware) 
+ services (désignation, persistance, transaction, sécurité...) 


Figure 2 - Composants, connecteurs et conteneurs 


dans les différents langages utilisés par les implémentations. À 
l'exécution, la communication entre les objets est construite sur le 
modèle client-serveur où seul le client connaît l'identité du serveur 
et initialise les échanges. 


Les bus de messages sont une approche complémentaire à celle 
de l'ORB en étendant le schéma de communication synchrone 
(client/serveur) par une communication asynchrone basée sur les 
événements. Plus précisément, les différents composants logiciels 
communiquent entre eux sans se connaître mais en utilisant les 
mécanismes d'offre de service et de demande de service, le rôle du 
bus étant d'appareiller les demandes. Ce mode de communication 
est particulièrement bien adapté aux environnements distribués qui 
regroupent différents utilisateurs pouvant se connecter dynamique- 
ment à des applications en cours d'exécution. 


CORBA et DCOM fournissent quelques mécanismes pour la confi- 
guration. Un composant peut être facilement remplacé par un autre 
en utilisant les propriétés d'héritage d'interface dans le cadre de 
CORBA, et l'agrégation ou la délégation dans le cadre de DCOM. La 
distribution des composants peut être dans certains cas configurée 
plus tard. Pour finir, différents mécanismes sont fournis afin de per- 
mettre à un objet de communiquer avec un autre qui n'est pas 
connu lors de la phase de compilation. CORBA possède l'appel 
dynamique et chaque objet DCOM peut mettre en œuvre une inter- 
face permettant à un objet client de connaître les services implé- 
mentés par le serveur. Malgré ces primitives, il nous semble très 
difficile de considérer CORBA et DCOM comme des plates-formes 
qui permettent la « reconfiguration » des applications car l'architec- 
ture de celle-ci n'est jamais exhibée et le code lié à la communi- 
cation est intégré à l'application. 


1.4 Architecture Description Language 


Différents projets ont adopté une approche où la programmation 
de l'application se fait à deux niveaux : le premier pour programmer 
les composants (programming in the small) et le second pour spéci- 
fier l'architecture de l'application (programming in the large). 
Conic [11] et Darwin [12] proposent des outils pour la programma- 
tion des applications distribuées mais ne prennent pas en compte le 
processus d'intégration des composants hétérogènes et la modifi- 
cation des protocoles de communication. Polylith [10] permet 
l'administration de composants hétérogènes mais l'architecture de 
l'application ne reflète pas le schéma d'instanciation des compo- 
sants. Dans Polylith, la modification du protocole de communication 
entre les composants impose de changer de bus logiciel et dépend 
donc de sa disponibilité. UniCon [13] ne permet pas de programmer 
des applications réparties mais introduit les connecteurs afin de 
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faciliter la configuration de la communication. Le projet Olan a 
adopté une approche similaire mais intègre dans un seul langage de 
configuration les aspects liés à la description de l'architecture de 
l'application, l'intégration de logiciels existants, la description du 
comportement dynamique, la gestion des attributs d’administra- 
tion. || propose aussi un environnement complet pour la génération 
du code de l'application et pour le déploiement des composants 
dans un environnement distribué hétérogène. 


1.5 Découvrir les composants 


Afin de pouvoir découvrir les différents composants, leurs maniè- 
res de communiquer et de construire dynamiquement l'assem- 
blage, un environnement de composants fournit toujours un 
mécanisme d'introspection et un mécanisme d'invocation dynami- 
que (le référentiel des interfaces et le DII de CORBAT15], l'API 
java.lang.reflect du langage Java [H 2 760]1IH 3 088], les interfaces 
IUnknown et IDispatch dans COM). L'introspection permet de 
découvrir à l'exécution les interfaces supportées par un composant 
ainsi que la signature des méthodes publiques. En Java, l'introspec- 
tion permet aussi de découvrir la structure interne des composants 
(les attributs). La sérialisation des objets Java met en œuvre ce 
mécanisme d'introspection de manière automatique (c'est-à-dire 
sans programmation). L'invocation dynamique permet de 
construire dynamiquement des requêtes sur les composants. 
L'association de ces deux mécanismes permet de construire des 
outils génériques d'interaction sur les composants tels que des foui- 
neurs (CorbaWeb), des langages de scripts (CorbaScript) [H 3 118], 
ou des outils de configuration/assemblage de composants. 


Cependant, un mécanisme d'introspection est inutile si l'on ne 
peut pas interpréter, de manière automatique, la sémantique asso- 
ciée aux méthodes. Pour cela, un modèle de composants peut pro- 
poser des design patterns de désignation des méthodes. Par 
exemple, le modèle de composants Java Beans propose un pattern 
simple pour désigner les propriétés (méthodes get et set) et les 
communications événementielles entre composants. Ainsi, les 
composants Java Beans peuvent être assemblés à travers des outils 
de construction visuelle. Ceux-ci exploitent les patterns pour trouver 
les propriétés configurables et les liens de composition des compo- 
sants. 


1.6 Packages de composants 


Une fois que les composants ont été assemblés visuellement, il 
est intéressant de sauver cette configuration dans un package pour 
une utilisation future. Ces packages de composants contiennent 
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sants (appelées aussi serveurs d'application) [2113]. Ces structures 
d'accueil fournissent l'environnement d'instanciation et d'exécution 
des composants et les mécanismes nécessaires pour faire commu- 
niquer ces composants. Les aspects de communication entre les 
composants ne sont pas insérés dans les aspects fonctionnels du 
composant afin de pouvoir fournir au dernier moment l'implémen- 
tation la plus appropriée. Dans le cas d'une application répartie, 
celle-ci sera déployée sur plusieurs structures d'accueil communi- 
quant par l'intermédiaire d'un middleware tel que CORBA (figure 2). 


Les structures d'accueil peuvent aussi prendre en charge de 
manière transparente des fonctions dites systèmes comme la dési- 
gnation symbolique, la persistance, la sécurité et les transactions. 
Cette prise en charge est paramétrée/configurée dans la description 
de l'application, elle n'est pas codée « en dur » dans les classes des 
composants. Ainsi, le code des composants se focalise uniquement 
sur les aspects fonctionnels/métiers. Les aspects systèmes sont 
gérés au niveau de la structure d'accueil. Un même code de compo- 
sant pourra être déployé avec des propriétés systèmes différentes 
{nom du composant, nom de la base de données, contrôle d'accès 
et modalité transactionnelle). Ici, les composants Microsoft, les 
Enterprise Java Beans et les composants CORBA offrent des solu- 
tions pour les architectures 3-parties : interfaces clientes-serveurs 
d'applications-gestionnaires de ressources (BD). 


1.8 Vers une vision industrielle 
des métiers du composant 


Actuellement, il n'existe pas de solution totalement satisfaisante 
offrant toutes les caractéristiques décrites précédemment. Cepen- 
dant, l'Object Management Group (OMG) travaille sur une vision 
globale de la notion de composant. Cette vision offre un modèle 
abstrait de composant permettant de capturer leurs propriétés, 
leurs relations de composition et leurs modes de communication 
(client/serveur et événement/réaction). Les interfaces des compo- 
sants sont décrites via une extension du langage OMG IDL (des 
constructions sémantiques plutôt que de simples patterns de dési- 
gnation). L'introspection et l'invocation dynamique sont déjà dispo- 
nibles dans CORBA. Le packaging de composants CORBA est réalisé 
par des archives ZIP. La description des composants et de l'architec- 
ture des applications est exprimée par l'intermédiaire du langage 
OSD (Open Software Description) qui est une DTD XML. Les API des 
structures d'accueil sont définies, ainsi que les relations entre celles- 
ci, et les services Nommage, Événement, Persistance, Sécurité et 
Transaction de CORBA. Sous certaines conditions, les structures 
d'accueil CORBA peuvent accueillir des composants EJB et inverse- 
ment. 


L'ensemble de cette norme est décrit par un métamodèle exprimé 
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a diversité des architectures matérielles et des systèmes d'exploitation pose 

le problème général de la portabilité des logiciels. La définition de la porta- 
bilité est donnée par la norme NF ISO/CEI 9126 Z67-133 d'octobre 1992: un 
ensemble d'attributs portant sur l'aptitude du logiciel à être transféré d’un envi- 
ronnement à l’autre, l'environnement pouvant être organisationnel, matériel ou 
logiciel. La définition, bien vague, recouvre des problèmes conceptuels et tech- 
niques qui n'ont pas de solutions définitives et absolues. Comme le soulignait 
B. Meyer en 1981 [12], la portabilité est à 99 % un problème ouvert. En une 
décennie, la situation n'a guère évolué, le signe le plus évident étant l'absence 
quasi totale d’écrits spécifiques sur le sujet. Si le but à atteindre est évident, les 
problèmes, les moyens et les solutions sont mal identifiés car trop fréquemment 
dépendants du logiciel concerné. La portabilité des logiciels est un facteur éco- 
nomique majeur de l'industrie informatique et les méthodes permettant de 
l'obtenir représentent un acquis fondamental du génie logiciel. 
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Au sein des entreprises, le problème de la portabilité se pose avec acuité car il 
est à présent rare qu'elles se contentent d’un seul constructeur, de ses machines 
et de ses systèmes d'exploitation propriétaires. Il importe donc que les applica- 
tions développées dans l'entreprise ou acquises par elle soient portables. De 
même, pour toute société désirant commercialiser un logiciel de sa conception, 
la rentabilité de son développement et de sa commercialisation suppose la por- 
tabilité. Pour les constructeurs, l'effet induit est une uniformisation obligée de 
leurs gammes de machines et de systèmes d'exploitation. AUA (Architecture 
Unifiée d’Applications) d'IBM [13] et [141], est un exemple typique de cette appro- 
che puisqu'elle propose un ensemble d'outils, de langages et de services dispo- 
nibles sur une gamme complète d'ordinateurs. Les développeurs, quant à eux, 
sont conduits à utiliser des méthodes permettant à leurs programmes de s’exé- 
cuter dans des contextes variés. 


Les quatre premiers paragraphes ont abordé la portabilité des logiciels tant du 
point de vue technique de la programmation et des langages que de celui plus 
méthodologique de l'organisation du logiciel et de son développement. Le lan- 
gage Java connaît une explosion médiatique peu commune. L'une de ses carac- 
téristiques est la portabilité de ses exécutables obtenue grâce au concept de 
machine virtuelle [10]. Ce concept qui n’est pas nouveau mais remis au goût du 
jour par Java est l'objet de cet article. Nous le comparons avec les deux autres 
techniques de mise en œuvre des langages que sont la compilation et l’interpré- 


tation. 


1. Facteurs de la portabilité 


La portabilité n'est pas liée à l'application mais induite par la 
conception et la mise en œuvre du logiciel. Le choix d’un langage et 
de méthodes de programmation en fonction des contraintes de 
l'application est déterminant. Une bonne organisation des program- 
mes et les principes respectés durant le développement détermine- 
ront le degré de portabilité. Si la phase de conception inclut des 
objectifs de portabilité, celle-ci peut être atteinte de manière raison- 
nable mais d’autres facteurs influent sur la portabilité. 


En premier lieu, un logiciel peut être dépendant d'un matériel 
donné. Un logiciel de simulation avec images de synthèse peut 
nécessiter un type d'écran particulier disponible uniquement sur 
une machine donnée et son système d'exploitation. La portabilité 
n'est même pas recherchée : on a plutôt tendance à vouloir tirer 
parti des caractéristiques de l'architecture. Ce type de logiciels a une 
fonction particulière dans un domaine précis et les critères de porta- 
bilité y ont peu d'importance car les systèmes informatiques sont 
dédiés : aéronautique, simulation de systèmes, contrôle de centra- 
les nucléaires, pilotage de machines, etc. 


La dépendance du logiciel par rapport au système d'exploitation 
est un facteur pouvant en restreindre la portabilité. Elle résulte sou- 
vent d’un choix volontaire : pour des raisons d'économie ou d'effi- 
cacité, on utilise des outils particuliers à un système, par exemple 
les fonctions de gestion d'écran. Dans ce cas, c'est la portabilité de 
l'interface utilisateur qui est perdue. Souvent, le défaut de portabi- 
lité induit concerne les interfaces à travers les méthodes d'accès aux 
périphériques. Cela ne remet pas fondamentalement en cause la 
portabilité du logiciel. Comme nous le verrons, une conception 
modulaire des programmes permet de minimiser l'impact de cette 
dépendance en isolant les fonctions non portables. Porter le logiciel 
sur un autre système revient à remplacer ces modules par d'autres. 
Enfin, les systèmes d'exploitation récents tendent à supporter 
autant que possible des outils natifs d'autres systèmes afin d'ame- 
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ner les développeurs d'application à effectuer, à un coût peu élevé, 
un portage leur offrant un nouveau marché. 


Un facteur commun entravant la portabilité d'un logiciel est sa 
dépendance vis-à-vis d'outils existants et nécessaires à son fonc- 
tionnement. C'est le cas par exemple de l'utilisation des systèmes 
de gestion de bases de données. Cependant, ce type d'outils subit 
généralement un processus d'uniformisation de ses interfaces 
jusqu'à l'obtention d'une norme. On observe des stratégies de 
commercialisation basées sur la normalisation de leurs interfaces 
de programmation ou du langage d'accès. 


De ces remarques préliminaires, il ressort que la portabilité totale 
d'un logiciel est une qualité pratiquement impossible à obtenir. Un 
logiciel peut être plus ou moins portable, c'est-à-dire que son por- 
tage demandera plus ou moins d'efforts selon les choix qui ont pré- 
sidé à sa conception et les méthodes qui ont été utilisées pour son 
développement. 


2. Choix et méthodes 


Lors de la conception d'un logiciel, il importe de faire les bons 
choix et d'utiliser des méthodes de programmation et de développe- 
ment permettant d'accroître son degré de portabilité. Résumons-les 
avant d'y revenir de manière plus détaillée : 


— le choix des plates-formes visées : tous les logiciels n'ont pas 
besoin d'être disponibles sur toutes les architectures et sur tous les 
systèmes d'exploitation ; 

— le choix du niveau d'intégration dans le système : en fonction 
de certaines contraintes, généralement de performances, il peut être 
nécessaire d'utiliser les fonctions particulières d'un système 
d'exploitation ; 

— le choix des outils : une application utilise souvent des outils 
logiciels et il est important de bien les choisir ; 
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— les méthodes de développement : dans cette catégorie, on 
retrouve les aspects techniques du génie logiciel : choix des langa- 
ges, du style de programmation, organisation des programmes, 
architecture du code exécutable. 


Alors que les trois premiers points sont parfois déterminés par 
l'application, le dernier point se révèle crucial car il s’agit de métho- 
des pouvant être appliquées à toute réalisation. 


2.1 Plates-formes 


Une plate-forme désigne une architecture matérielle et son sys- 
tème d'exploitation. Un logiciel n'a pas toujours de vocation univer- 
selle et le nombre des plates-formes sur lesquelles il doit être 
disponible est à déterminer. Un développeur peut être amené à 
cibler un constructeur et l’une de ses gammes. Cela se révélera ren- 
table si cette gamme de matériel possède des caractéristiques maté- 
rielles et logicielles communes. Effectuer un tel choix suppose la 
pérennité des orientations techniques du constructeur mais aussi 
une informatisation cohérente de la part des utilisateurs. On peut 
cibler une gamme surtout si le logiciel est destiné à un secteur infor- 
matique bien précis. Dans certains secteurs industriels ou économi- 
ques, comme ceux des assurances ou des banques par exemple, il 
existe de grandes entreprises dont le parc informatique est relative- 
ment uniforme. 


2-2 Niveau d'intégration 


Les systèmes d'exploitation possèdent des particularités à pren- 
dre en compte afin d'améliorer les performances ou l'ergonomie 
d'un logiciel. Ainsi certains gèrent très efficacement les méthodes 
d'accès direct aux enregistrements d’un fichier (VM/CMS par exem- 
ple) alors que certains autres ne supportent pleinement que la 
méthode d'accès séquentiel (Unix ou OS/2 par exemple). Utiliser 
l'accès direct peut rendre le logiciel performant sur le premier type 
de systèmes mais pas sur le second. Dans cette catégorie, on peut 
également placer les outils particuliers à un système d'exploitation 
ou l'utilisation de certaines fonctions typiques du système. Choisir 
de restreindre la portabilité à des machines couvertes par un même 
système d'exploitation permet d'aller loin dans cette voie sans enta- 
mer la portabilité recherchée. Il convient d'être prudent quant à la 
disponibilité réelle de telles fonctions. Il est courant que les paramè- 
tres d'utilisation de la fonction diffèrent sensiblement en haut et en 


3. Méthodes 
de développement 


Alors que les choix précédents relèvent du bon sens et de l'infor- 
mation, les principes suivants relèvent de la méthodologie et sont 
relativement indépendants de l'application. 


3.1 Langages 


Le choix des langages dans lesquels sera développée l'appli- 
cation est très important. Si ces langages ne sont pas portés, l'appli- 
cation ne le sera pas non plus sans une réécriture. 


3.1.1 Utiliser un langage normalisé 


Une première solution est d'utiliser un langage connu pour sa 
portabilité. Il faut prendre garde que les meilleures réputations sont 
parfois surfaites. Certaines données techniques du langage sont 
souvent dépendantes de l'architecture matérielle qui les supporte. 
Ainsi, un entier peut être représenté sur 16, 32 ou 64 bits selon les 
processeurs. De même, on peut utiliser certaines caractéristiques 
relatives aux appels de sous-programmes qui ne seront pas univer- 
sellement respectées par tous les compilateurs. Ces deux problè- 
mes ont été rencontrés lors du portage d'un programme 
conséquent écrit en langage C, pourtant l'un des plus portables, 
depuis OS/2 1.3 vers OS/2 2.0. Le compilateur du langage C pour 
OS/2 1.3 était réalisé par Microsoft tandis que celui pour OS/2 2.0 
l'était par IBM. On peut arguer que les fournisseurs des compila- 
teurs n'ont pas effectué un excellent travail mais ce n'est pas exact 
car deux remarques s'imposent. La première est que le fournisseur 
du compilateur est lié par des contraintes matérielles imposées par 
l'architecture et par des objectifs d'efficacité. Si le code généré par 
son compilateur n'était pas efficace, il ne serait pas utilisé. La 
deuxième est que, moyennant quelques précautions, il est néan- 
moins possible d'écrire un code relativement portable au prix de 
quelques sacrifices sur les performances. 


Donc, si le choix se porte sur un langage existant, il est nécessaire 
de vérifier les différentes versions du compilateur qui seront utili- 
sées, d'en mesurer les performances et d'en isoler les caractéristi- 
ques techniques : format des données, réalisation des appels de 
sous-programmes, limitations diverses telles que taille des pro- 
grammes et des sous-programmes, taille de l'espace mémoire 
adressable. taille des fichiers. etc. En effet. elles neuvent influer sur 
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n processus est « un ensemble d'activités corrélées ou interactives qui 

transforme des éléments d'entrée en éléments de sortie ». Cette définition 
(ISO 9000 : 2000) s'applique parfaitement au traitement de l'information. En 
effet, nous sommes en présence d'un ensemble constitué de mécanismes (le 
matériel) qui effectuent des processus automatiques conformément à un pro- 
gramme préétabli (le logiciel). 
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A:> l'ère agraire nos civilisations sont passées par l'ère industrielle avec 
son machinisme, puis nous sommes arrivés à l'ère de l'information et de 
la dématérialisation. Les métiers se transforment en fonction des exigences de 
ce nouveau type d'économie. 


Les fabricants de produits manufacturés intègrent de plus en plus de services 
dans leur offre. À tel point que parfois, ce sont les services offerts qui sont mis 
en avant commercialement et qui sont rémunérateurs. Les produits deviennent 
si peu importants qu'ils sont parfois donnés gratuitement. 


Afin de promouvoir la qualité de leurs produits, les fabricants ont recherché 
des moyens de se différencier par rapport à leurs concurrents. Pour les aider 
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dans ce domaine, l'International Organization for Standardization (ISO) a 
développé des normes et la possibilité de certifier leur système de manage- 
ment par rapport à ces normes. Aujourd'hui, il en est de même pour les 
fournisseurs de prestations de service Information Technology. 


Dans ce domaine, au lieu de partir d'une réflexion théorique et de bâtir un 
« système » complexe et difficile à mettre en œuvre, la profession a bénéficié 
des bonnes pratiques issues du terrain et collectées au sein de la méthodo- 
logie ITIL®. Sur cette base opérationnelle de l'exploitation informatique sont 
organisés des processus clairement identifiés avec leurs règles de saine ges- 
tion. Ce canevas de bonnes pratiques a été repris par l'ISO et complété avec 
les éléments nécessaires pour structurer un Système de Management des Ser- 
vices. Le résultat est contenu dans les deux normes ISO/CEI 20000. Tout 
fournisseur de service IT peut, sous réserve de répondre aux exigences de la 
première partie de ces normes, être candidat à l'obtention du certificat. L'objet 
de cet article est d'indiquer quels sont les facteurs de succès pour s'y préparer 


efficacement. 


1. Référentiel de bonnes 
pratiques ITIL® 


1.1 ITIL, qu'est-ce que c'est ? 


Tout d'abord, le mot ITIL® est un acronyme composé des pre- 
mières lettres des quatre mots suivants : 

INFORMATION ; 

TECHNOLOGY ; 

INFRASTRUCTURE ; 

LIBRARY. 


Nous pouvons traduire en français ces titres par « bibliothèque 
de l'infrastructure des technologies de l'information ». 


Dans les années 1980, après les difficultés de coordination des 
différents systèmes informatiques constatées lors de la prépara- 
tion de la guerre des Malouines, le gouvernement de Margaret 
Thatcher impose aux administrations publiques britanniques une 
politique de mise en concurrence systématique avec les acteurs 
privés. Un groupe de travail, le Central Computer and Tele- 
communications Agency (CCTA), est constitué avec pour objectif 
d'améliorer l'efficacité et la qualité des prestations des services 
informatiques des ministères. Cette agence deviendra l'Office of 
Government Commerce (OGC). 


En fait, ITIL® n'est ni une norme ni une méthode, mais un 
ensemble des meilleures pratiques en matière de gestion de la 
production informatique. L'objectif étant que tous les informati- 
ciens utilisent le même vocabulaire et les mêmes processus quel 
que soit leur administration de rattachement. 


Plusieurs versions ont été publiées à ce jour : 


-— la version 1; 
-— la version 2; 
- la version 3. 


1.2 Version 1 


Les résultats des travaux du groupe constitué de onze 
consultants furent la publication de la première version lancée par 
le gouvernement britannique. 

Cette version 1 de l'ITIL® était constituée de 40 livres. Le premier 
ouvrage dont le titre était « Service Level Management » a été 
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publié en 1989. Le dernier ouvrage de cette série dont le titre était 
« Availability Management Book » a été publié en 1996. 


1.3 Version 2 


Cette version a été élaborée entre le milieu des années 1990 et 
2004. Elle regroupe les éléments de la version 1 et organise les 
prestations de service liés aux technologies de l'information selon 
huit domaines. 


Cette version a produit neuf livres dont seulement 2 ont forgé la 
réputation de ITIL”. Ils sont les plus connus et utilisés aujourd'hui : 

— Service Support ; 

— Service Delivery. 


1.3.1 Huit domaines 


— Business Perspective : prise en compte des structures d'orga- 
nisation, rôles et responsabilités (livre publié en novembre 2004) ; 

— Application Management : prise en compte de la gestion des 
relations entre les études et l'exploitation (livre publié en 
septembre 2002) ; 

— Software Asset Management : prise en compte de l'évaluation 
du logiciel (livre publié en septembre 2003) ; 

— ICT Infrastructure Management : prise en compte du cycle de 
vie de l'infrastructure (livre publié en octobre 2002) ; 

— Security Management : prise en compte globale et la mise en 
place de la sécurité informatique (livre publié en avril 1999) ; 

— Planning to Implement Service Management : prise en compte 
d'une approche service (livre publié en avril 2002) ; 

— Service Delivery: prise en compte de la planification et de 
l'amélioration de la fourniture des services (livre publié en avril 
2001) ; 

— Service Support: prise en compte globale des opérations au 
jour le jour du support aux services (livre publié en juin 2000). 


De ces huit domaines, seulement les deux derniers ont forgé la 
réputation de lITIL®. Ils sont les plus connus et utilisés 
aujourd'hui, à savoir. 


1.3.2 Soutien des services (Service Support) 


Ce livre (appelé aussi livre bleu) traite des thèmes suivants : 

- le centre de services (Service Desk) est une fonction de l'orga- 
nisation des T|; 

- la gestion des incidents (/ncident Management) ; 
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Figure 1 - Cadre des publications de l'ITIL® version 2 


- la gestion des problèmes (Problem Management) ; 

— la gestion des configurations (Configuration Management) ; 
— la gestion des changements (Change Management) ; 

- la gestion des mises en production (Release Management). 


1.3.3 Fourniture des services (Service Delivery) 


Ce livre (appelé aussi livre rouge) traite des thèmes suivants : 

- la gestion des niveaux de service (Service Level Management 
ou SLM) ; 

- la gestion financière des services des TI (/T Service Financial 
Management) ; 

- la gestion de la capacité (Capacity Management) ; 

- la gestion de la disponibilité (Availability Management) ; 

-la gestion de la continuité des services des TI (/T Service 
Continuity Management). 


En résumé, l'ITIL® version 2, est organisé autour d'une fonction 
organisationnelle : le centre de service, de cinq processus opéra- 
tionnels (Service Delivery) et six processus tactiques (Service 
Support). La figure 1 représente la cartographie des publications 
de l'ITIL® version 2. 


1.4 Version 3 


Une initiative de mise à jour majeure a été lancée en 2004. La 
nouvelle librairie, publiée de mai à août 2007, comprend mainte- 
nant un noyau de six livres (en fait, 5 livres + 1 livre) : les « Core 
proactive books ». 


Les six livres du noyau sont les suivants : 
1) Introduction au cycle de vie des Services ITIL®. Ce cycle de 
vie des services comporte trois étapes : 
ela première étape qui va de l'étude d'opportunité jusqu'à la 
mise en œuvre en passant par le développement, 
e la deuxième étape avec mise au catalogue et exploitation du 
service, 
ela troisième étape qui correspond à l'arrêt et au retrait du 
service ; 


2) Stratégie des services (Service Strategy). Ce livre concerne 
les directions générales et vise l'alignement du Système d'Infor- 
mation avec la stratégie Business de l’entreprise. Ce livre recouvre 
les processus suivants : 

e la gestion de la demande (Demand Management), 
ela gestion du portefeuille des services (Service Portfolio 
Management), 


e la gestion financière des TI (/T Financial Management) ; 
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Figure 2 - Noyau des publications de l'ITIL® version 3 


3) Conception des services (Service Design). Ce livre contient 
les six processus tactiques du service support de la version 2: 
catalogue, niveaux de services, capacité, disponibilité, continuité, 
sécurité, et un nouveau processus de gestion des fournisseurs 
(Supplier Management) ; 

4) Transition (passage en production) des services (Service 
Transition). Ce livre recouvre les processus suivants : 

e la gestion des changements, 
e la gestion des mises en production scindé en quatre parties : 

— planification et support (Service transition and support) ; 

— gestion des livraisons et déploiements (Release and Deploy- 
ment Management) ; 

- test et validation des services (Service validation and testing) ; 

— évaluation de la performance d'un service (Evaluation) ; 

e la gestion des configurations, 
eet un nouveau processus de gestion des connaissances 
(Knowledge Management). 

5) Exploitation des services (Service Operation). Ce livre 
concerne les activités quotidiennes, à savoir les processus 
suivants : 

e la gestion des incidents, 

e la gestion des problèmes, 

e la gestion des évènements (Event Management), 

e la gestion des demandes (Request Fulfillment), 

e la gestion des accès (Access Management), 

e la gestion des opérations (Operation Management) ; 

6) Amélioration permanente des services (Continual Service 
Improvement). Ce livre concerne les activités de vérification avec 
reporting et tableaux de bord. Lorsqu'une dérive est constatée, des 
actions correctives doivent être mises en œuvre. 


La figure 2 représente la cartographie des publications du noyau 
de l'ITIL® version 3. 


À ce noyau devraient venir s'ajouter des livres complémentaires 
plus spécialisés sur des sujets donnés tels que : 

— governance methods ; 

— complimentary guidance ; 

— quick wins ; 

— case studies ; 

— study aids ; 

— qualifications ; 

— value added products ; 

— templates. 
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1.5 Acteurs de l'ITIL® 


Les utilisateurs de l'ITIL® sont regroupés dans une association : 
l'tSMF (Information Technology Service Management Forum). Le 
site français est à l'adresse suivante : www.itsmf.fr. 


L'OGC (Office of Government Commerce) assure la promotion 
du référentiel des bonnes pratiques. Le site de l'OGC est à 
l'adresse suivante : www.ogc.gov.uk. 


L'ISEB (/nformation Systems Examination Board, anglais) et 
l'EXIN (Examination Institute, hollandais) ont la responsabilité des 
programmes de certification des personnes. Le site de l'ISEB est à 
l'adresse suivante : www.bcs.org/ server.php?show=nav.6940 et le 
site de l'EXIN est à l'adresse suivante : www.exin-exams.com. 


1.6 Certifications ITIL® 


En matière de certification, il existe une différence essentielle 
entre les certifications proposées dans le cadre de l'ITIL” et les cer- 
tifications proposées par l'ISO. 


En effet, le référentiel de bonnes pratiques ITIL® permet exclusi- 
vement une certification de personnes (donc seule la personne 
physique détient le diplôme et elle l'emporte avec elle lorsqu'elle 
quitte l'entreprise). Dans le cadre de l'ISO, c'est le système de 
management des services qui est certifié (donc l'organisation de 
l'entreprise, personne morale qui détient le diplôme). 


Trois niveaux de certification de personnes sont accessibles si le 
candidat répond à un ensemble d'exigences : 

- le niveau 1 : Fondamentaux (Foundation). Ce niveau concerne 
ceux qui s'intéressent à ITIL” ; 

- le niveau 2 : Expert (Pratictioner). Ce niveau concerne ceux qui 
pratiquent la gestion des services IT ; 

-le niveau 3: Directeur en gestion des services IT (Service 
Manager). Ce niveau concerne ceux qui implémentent les 
processus. 


Aux certifications initiales pour la version 2 se sont ajoutées des 
certifications pour la version 3: 

— passerelle (Bridge V2V3) pour les niveaux Foundation et Ser- 
vice Manager ; 

— ITIL /ntermediate Capability (sur chacun des thèmes : support, 
mise en production, planification, cycle de vie ..….) pour le niveau 
Pratictioner. 


Pour ce qui concerne les certifications ISO, le lecteur se repor- 
tera au chapitre « les apports de la certification ». 


2. Norme BS 15000 


2.1 Norme BS 15000, qu'est-ce que 
c'est ? 


Première norme de gestion des services informatiques, 
BS 15000 est une norme nationale développée par le British Stan- 
dards Institute (Institut Britannique de Normalisation ou BSI, repré- 
sentant l'ISO en Angleterre, équivalent de l'AFNOR en France). La 
portée de cette norme est donc essentiellement limitée au péri- 
mètre britannique. Par contre, sa structure et son contenu ont été 
« portés » à l'international dans le cadre de l'ISO. C'est l'ancêtre de 
l'ISO/CEI 20000. 


2.2 Structure de la norme BS 15000 


Un premier texte a été publié par le BSI en novembre 2000, inti- 
tulé Specification for IT service management. 


La norme BS 15000 Information Technology se compose de 
deux parties. 


La partie 1, /T service management. Specification for service 
management publiée en septembre 2002. Ces spécifications 
décrivent les exigences de la norme incontournables pour une 
mise en conformité. 


La partie 2, IT service management. Code of practice for service 
management publiée en janvier 2003. Ce code des meilleures pra- 
tiques propose des conseils aux fournisseurs de services pour les 
aider dans les travaux de mise en conformité avec les exigences 
de la norme. 


2.3 Avantages de la norme BS 15000 


Par rapport à l'ITIL, qui n'est qu'un ensemble de bonnes 
pratiques, la norme BS 15000 offre une structure formelle 
permettant d'auditer, puis, à partir des résultats de cet audit, de 
certifier un système de management des prestations de service 
informatique. 


Cette norme d'origine britannique constitue le fondement de la 
norme internationale ISO/CEI 20000. 


3. Norme internationale 
ISO/CEI 20000 


3.1 ISO 20000, qu'est-ce que c'est ? 


La norme britannique BS 15000 a été proposée au niveau inter- 
national au mois de novembre 2005. La procédure utilisée à l'ISO a 
été la procédure accélérée. Ainsi, elle a permis une publication 
officielle en anglais le 15 décembre 2005 sous le titre 
ISO/IEC 20000 /nformation Technology - service management. 


Ensuite, pour sa version française, l'AFNOR en a repris le texte 
intégralement et l'a publié le 12 janvier 2006. 


Comme la norme BS 15000, l'ISO/CEI 20000 comporte deux par- 
ties. À remarquer : seule la partie 1 spécification a été traduite en 
français. 


Les fondamentaux de cette norme internationale reposent sur : 


— l'approche processus ; 

la prise en compte du cercle vertueux Plan, Do, Check, Act 
(PDCA) ; 

—la maîtrise des activités et des ressources nécessaires aux 
services ; 

— la formalisation d'un système de management des services. 


Nota : ISO est le sigle de International Organization for Standardization. CEI est le sigle 
de Commission Électrotechnique Internationale (en Français) ou IEC pour International 
Electrotechnical Commission (en Anglais). 


3.2 ISO/CEI 20000 - Partie 1 


La première partie, Specification for service management (Spéci- 
fication de la gestion des services), précise les exigences qu'une 
organisation candidate à la certification doit nécessairement satis- 
faire. 


Le paragraphe 17 présente le sommaire de la partie 1 de la 
norme. 
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3.3 ISO/CEI 20000 - Partie 2 


La deuxième partie, Code of practice for service management 
(Code de pratiques de gestion de services), propose des conseils 
pratiques aux fournisseurs de services dans la mise en œuvre du 
système de management des services en conformité avec les exi- 
gences de la première partie. 


Le paragraphe 17 présente le sommaire de la partie 2 de la 
norme. 


3.4 Domaine d'application 
de l'ISO/CEI 20000 


Le fournisseur de services IT (/nformation Technology) doit 
répondre aux besoins de ses clients et délivrer des prestations 
informatiques de qualité. Pour y parvenir et maîtriser ses presta- 
tions de service il doit organiser ses activités sous la forme de pro- 
cessus. C'est l'approche processus recommandée par la norme 
internationale. 


Nous remarquerons que l'ISO a identifié 15 processus 
(continuité et disponibilité sont regroupés dans un même article de 
même que budgétisation et comptabilisation) qui sont regroupés 
en cinq familles. Ces processus sont listés ci-dessous dans l'ordre 
de leur apparition dans la norme internationale. 


B Processus de fourniture de services (Service Delivery Processes) 
Nota : : ce groupe de processus correspond à l’article 6 de la norme internationale. 


— gestion des niveaux de service (Service Level Management) ; 

— rapport de service (Service Reporting) ; 

— gestion de la continuité et de la disponibilité du service (Ser- 
vice continuity and Availability Management) ; 

— budgétisation et comptabilisation des services informatiques 
(Budgeting and Accounting for IT services) ; 

— gestion de la capacité (Capacity Management) ; 

— gestion de la sécurité de l'information (/nformation Security 
Management). 


B Processus de gestion des relations (Relationship Processes) 
Nota : : ce groupe de processus correspond à l’article 7 de la norme internationale. 


— gestion des relations commerciales (Business Relationship 
Management) ; 
— gestion des fournisseurs (Supplier Management). 


B Processus de résolution (Resolution Processes) 
Nota : : ce groupe de processus correspond à l’article 8 de la norme internationale. 


— gestion des incidents (/ncident Management) ; 
— gestion des problèmes (Problem Management). 


B Processus de contrôle (Control Processes) 
Nota : ce groupe de processus correspond à l’article 9 de la norme internationale. 


— gestion des configurations (Configuration Management) ; 
— gestion des changements (Change Management). 


B Processus de mise en production (Release Processes) 
Nota : ce groupe de processus correspond à l’article 10 de la norme internationale. 


— gestion des mises en production (Release Management). 


À remarquer que les processus «rapport de service» et 
« gestion des relations » n’existaient pas dans l'ITIL® V2. Le pro- 
cessus de « gestion financière » de l'ITIL® a été scindé en deux 
(budgétisation et comptabilisation). 

En outre, par rapport à l'ITIL® la norme ISO/CEI 20000 introduit 
la notion de Système de Management (inspiré du Système de 
Management de la Qualité exigé par la norme ISO 9001). Pour 
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Figure 3 - Cartographie des processus de l'ISO/CEI 20000 


définir cette exigence de système de management, l'ISO/CEI 
comporte trois articles qui viennent compléter les processus : 


a) Les exigences d'un système de gestion des services (article 3 
de la norme), avec les exigences suivantes : 

- responsabilité de la direction ; 

— exigences relatives à la documentation ; 

- compétence, sensibilisation et formation. 

b) La planification et mise en œuvre de la gestion des services 
(article 4 de la norme), avec les exigences suivantes : 

— planification de la gestion des services (Planifier - Plan) ; 

— mise en œuvre de la gestion des services et fourniture des ser- 
vices (Faire - Do); 

- surveillance, mesure et revue (Vérifier - Check) ; 

— amélioration continue (Agir - Act). 


c) La planification et mise en œuvre des services nouveaux ou 
modifiés (article 5 de la norme). 


La figure 3 présente la cartographie des processus de la norme. 


3.5 Évolutions prévisibles 
de l'ISO/CEI 20000 


Un certain nombre de travaux sont en cours au sein des groupes 
d'experts internationaux de l'ISO. Ces travaux sont en train de des- 
siner ce que devrait être la prochaine version de la norme 
ISO/CEI 20000. À ce jour, les éléments d'informations disponibles 
concernent : 


3.5.1 Partie 1 


Les exigences qui concernent le système de management des 
services devraient concerner n'importe quel type de service (et pas 
uniquement les services /nformation Technology). 


3.5.2 Partie 2 


Cette deuxième partie devrait s'aligner sur la prochaine version 
de la partie 1. 


3.5.3 Partie 3 


Cette troisième partie éditée sous forme de rapport technique (et 
non de norme) en novembre 2009 apporte des directives pour la 
définition du domaine d'application et l'applicabilité de l'ISO/IEC 
20000-1. 
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3.5.4 Partie 4 


Cette quatrième partie concernera le modèle de référence des 
processus, Process Reference Model (PRM). Ce document devrait 
s'appuyer sur la norme ISO/CEI 15504-2 : 2003 Information Techno- 
logy -— Process assessment - Performing an assessment qui décrit 
les exigences d'un modèle de référence de processus. On devrait y 
retrouver la liste et les descriptions standardisées des processus, 
rangés par famille de processus : 


— groupe de processus de management (MAN) ; 

— groupe de processus de planification et d'implémentation 
(PLA) ; 

- groupe de processus de fourniture de services (SDE) ; 

— groupe des processus de contrôle (CON) ; 

— groupe de processus de résolution (RES) ; 

— groupe de processus de mise en production (RLS) ; 

— groupe de processus de relations (REL). 


3.5.5 Partie 5 


Cette cinquième partie éditée sous forme de rapport technique 
(et non de norme) en mai 2010 apporte un exemple de plan de 
mise en application pour l'ISO/CEI 20000. 


3.5.6 Partie ISO/CEI 15504-8 


Cette partie sera baptisée 15504 et non pas 20000. En effet, elle 
devrait être semblable à cette famille de normes qui traitent de 
l'évaluation des processus d'ingénierie logiciel (inspirée de l'éva- 
luation CMMI avec ses niveaux de maturité). 


Nota : le Capability Maturity Model (CMM) a été développé par le Software Enginee- 
ring Institute (SEl) de Pittsburg, initialement pour sélectionner les fournisseurs du 
département de la Défense des États-Unis. 


Cette partie n° 8 de l'ISO 15504 fournit un exemple pour un 
modèle d'évaluation de processus, Process Assessment Model 
(PAM) avec des indicateurs d'évaluation. 


Principe de l'évaluation de processus. 


Le processus d'évaluation (PAM) pour les processus des 
services fait référence au modèle de référence de processus (PRM) 
pour les processus des services tel que devrait être défini dans la 
norme ISO/CEI 20000-4 de manière analogue à la norme 
ISO/CEI 15504-2 qui définit le modèle de référence pour les proces- 
sus d'ingénierie de logiciel. 


Ensuite, l'évaluation de processus se pratique selon deux axes 
ou dimensions : 


Produit : bien économique issu de la production, objet manu- 
facturé. 


Service : ensemble d'obligations envers des individus ou des 
collectivités. 


La norme internationale 9000:2005 nous donne la définition sui- 
vante pour un service en général : 


Un service comme un produit est le résultat d'un processus. 


Un service est le résultat d'au moins une activité néces- 
sairement réalisée à l'interface entre le fournisseur et le client. 
Il est généralement immatériel. 


Par contre, la norme ISO/CEI 20000 ne donne pas une définition 
standardisée d'un service Information Technology. En lieu et place, 
le groupe de travail itSMF-AFNOR a choisi de retenir la définition 
suivante : 


« Un service est une prestation immatérielle composable, 
manifestée de manière perceptible, et qui, dans une condition 
d'utilisation prédéfinie, est source de valeur pour le 
consommateur et le fournisseur ». 


Nota: source, document «ITIL et ISO 20000: mise en œuvre opérationnelle », 
publié le 19 janvier 2007 par STANDARMEDIA-AFNOR (disponible sur le site 
www.standarmedia.com, onglet « études »). 


4.2 Composantes d'un service 


Un service est rarement quelque chose de monolithique. 
Comme un édifice, un service est généralement le résultat d'un 
assemblage d'un nombre plus ou moins important de 
sous-ensemble qui, chacun ont leur fonction propre. 


Cette modularité a l'avantage de pouvoir composer un service à 
partir de « briques », chaque brique étant elle-même gérée et tes- 
tée séparément. Une telle architecture permet de proposer au 
client des prestations de services plus personnalisées. Le client a 
ainsi la possibilité de choisir dans un « catalogue » les différents 
composants qui correspondent le mieux à ses besoins. 


Le contenu du catalogue de services matérialise l'ensemble dés 
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La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 


Si vous souhaitez accéder au contenu intégral de cette base documentaire, rendez-vous 


à la fin de ce document. 


Et pour toute question sur nos offres d'abonnement, n'hésitez pas à contacter le service 
Relation clientèle au 01 53 35 20 20 ou par email à l'adresse infos.clients@teching.com. 
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L= systèmes embarqués sont soumis à de nombreuses contraintes et 
certains sont en interaction étroite avec des procédés dangereux ou inter- 
viennent dans des processus de décisions impactant des vies humaines. Le 
développement de tels systèmes doit offrir des garanties de bon fonction- 
nement et de bon rétablissement en cas de défaillance d'une partie interne ou 
d'un environnement non prévu. 


Des méthodes de vérifications formelles peuvent être mises en œuvre pour 
augmenter le degré de confiance des systèmes. Trois grandes classes se 
distinguent : 

— la preuve assistée (theorem-proving) ; 

— la vérification par modèle (model-checking) et ses nombreuses variantes 
et extensions ; 

— enfin le raffinement de spécification. 


On présente le positionnement de ces approches dans le flot de conception 
des systèmes embarqués. 


Pour chaque approche, on s'attache à présenter simplement le principe de 
base, le domaine applicatif principal, les outils disponibles ainsi que les réalisa- 
tions académiques et industrielles. Cet article n'utilise pas de formalisme 
mathématique poussé pour être accessible au plus grand nombre. Les réfé- 
rences bibliographiques permettent d'approfondir chaque approche tant sur 
les aspects formels que sur les outils disponibles ou (le cas échéant) leur utili- 
sation dans un contexte industriel. 
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Principaux sigles 
Sigle Signification Commentaire 
OS Operating System Système d'exploitation 
FPGA Field Programmable Circuit logique 
Gate Array programmable 
C# C sharp Langage de 
programmation pour les 
composants 
DMA Direct Memory Access Dispositif matériel chargé 
des transferts de données 
entre les périphériques et 
la mémoire 
VHDL VHSIC Hardware Langage de description de 
Description Language systèmes de matériel 
| 
VHSIC | Very-High-Speed Inte- … °°TP'EXES 
grated Circuits 
RTL Register Transfer Level | Niveau de description de 
systèmes matériels : 
transfert de registre 
CABA Cycle Accurate Bit Niveau de description de 
Accurate systèmes matériels : précis 
au cycle près et au bit près 
TLM Transation Level Niveau de description de 
Modelling systèmes matériels : 
niveau abstrait dans lequel 
les échanges sont 
matérialisés par des 
transactions de type 
requête/réponse 
TIC Technologies de Technologies de 
l'Information et des l'Information et des 
Communications Communications 


1. Conception des systèmes 
embarqués 


Les systèmes embarqués réalisent des tâches complexes de trai- 
tement d'information, en interaction étroite avec l'environnement 
dans lequel ils sont plongés. Ces traitements d'information sont 
réalisés par des composants électroniques agissant sur des parties 
mécaniques par le biais de capteurs/actionneurs. Les systèmes 
embarqués sont très divers et présentent des architectures et 
modes d'utilisation variés [H 8 0001]. 


Les traitements informatiques à réaliser peuvent être décrits 
sous la forme de programmes, exécutés sur des contrôleurs ou 
des cœurs de processeurs, mais ils peuvent également être 
implantés dans des coprocesseurs dédiés, accélérant leur exé- 
cution. Les interactions avec le monde physique sont réalisées par 
le biais de capteurs/actionneurs. Les communications hertziennes 
nécessitent l'emploi de composants analogiques permettant la 
mise en forme, l'émission, la réception de signaux analogiques, 
ainsi que des dispositifs de conversion de signaux analo- 
giques/numériques et numériques/analogiques. Les systèmes 
embarqués présentent des contraintes qui les distinguent des 
systèmes informatiques en général : 

—ils présentent une forte réactivité à l'environnement qu'ils 
contrôlent (par exemple, la commande d'injection de carburant 
dans un moteur automobile, le contrôle des volets des ailes 
d'avion, l'identification et le retour aptique des manettes de 
console de jeu) ; 


Application 


Partitionnement 
Matériel/Logiciel 


Architecture matérielle 
SysML, SystemC-TLM 


Architecture logicielle 
UML, Composants 


Composant matériel 
SystemC-VHDL, SystemVerilog 


Composant logiciel 
Ada, C#, C... 


Déploiement de 
l'application 


Figure 1 - Flot de conception classique du développement 
d'une application embarquée 


—ils présentent des contraintes liées à l'embarcation: poids, 
taille, consommation, éventuellement milieu hostile (température, 
rayonnement ionisant, milieu acide) comme dans le cas de satel- 
lites, robot martien, sonde endoscopique. 

Les volumes de produits à concevoir sont extrêmement 
variables : quelques dizaines d'unités (satellite) à quelques millions 
d'unités (téléphone portable). 


Flot de conception. Le système à réaliser est généralement 
modélisé à différents niveaux d'abstraction afin de pouvoir 
être simulé et testé fonctionnellement avant sa réalisation 
physique (figure 1). 


L'application, décrite sous la forme d'un ensemble de tâches 
concurrentes, est partitionnée : on identifie les tâches qui seront 
réalisées sous forme logicielle (un programme s’exécutant sur un 
cœur de processeur) et celles à implanter dans un coprocesseur 
matériel dédié. On peut procéder à une étape d'exploration archi- 
tecturale pour déterminer le meilleur partitionnement du graphe 
des tâches de l'application et son plongement sur différents 
éléments matériels. Chaque élément est alors modélisé dans un 
langage de description, permettant d'analyser le système (essen- 
tiellement par simulation) et d'en synthétiser une représentation 
exécutable (compilation du logiciel pour l'OS et le cœur de proces- 
seur choisi, réalisation physique sur FPGA des coprocesseurs 
matériels). Il existe de nombreux langages de modélisation des 
parties logicielles et des composants électroniques. On distingue : 

- les langages de programmation des parties logicielles (Ada, 
C#, Cl: 

- les langages de description de plate-formes matérielles (Sys- 
temC, SystemVerilog) permettant de décrire l'assemblage de 
cœurs de processeurs, réseaux, coprocesseurs matériels, bancs 
mémoire, DMA, interface réseau ; 

-les langages de description de matériel (VHDL, Verilog) 
permettant de synthétiser (sous certaines hypothèses) les 
éléments matériels ou une implantation sur FPGA. 


Les approches synchrones (Scade, Esterel) offrent quant à elles 
un formalisme unifié pour décrire les éléments logiciels et maté- 
riels ainsi que des outils de compilation vers C pour les parties 
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logicielles et des outils de synthèse logiques (niveau RTL) pour les 
parties matérielles. 


Les modèles ainsi construits sont essentiellement testés par 
simulation fonctionnelle suivant un plan de test dont la complexité 
dépend du niveau d'assurance à atteindre. Les modèles sont testés 
individuellement et en interactions. Des plates-formes de cosimu- 
lation matériel/logiciel sont également utilisées. 


En pratique, les éléments (matériels et logiciels) du système peu- 
vent être réalisés par des groupes de développement ou entreprises 
différentes les unes des autres. Chaque élément est défini par son 
interface, l'ensemble des services qu'il fournit, ainsi qu'une implan- 
tation physique de ses services. La description de l'interface et des 
services fournis peut être sous forme textuelle ou formalisée. Cha- 
que élément est validé individuellement, puis on procède à l'inté- 
gration des différents éléments, qui doit également être validée. 


Pour les applications à évolution rapide et dispensées en 
grandes séries avec multitudes d'options, le flot de conception fait 
grand usage de la réutilisation de composants. 


Exemple : lors de la conception d'un nouveau téléphone portable, 
on réutilise certains composants de la version précédente d'un télé- 
phone portable du même constructeur, où alors on ajoute des fonc- 
tionnalités à un composant déjà existant. 


Si ce principe semble naturel, la réutilisation d'un composant 
dans un nouveau contexte nécessite une nouvelle validation de 
l'intégration ; de même, lors de l'ajout d'une fonctionnalité à un 
composant, il faut s'assurer que la modification n'entraîne pas de 
dégradation dans les services préalablement fournis par le 
composant. Ces propriétés sont difficiles à tester par simulation. 


Dans le processus de conception d'un système embarqué, la 
part de la simulation/vérification est de plus en plus importante et 
peut représenter jusqu'à 70 % du temps de conception. La simu- 
lation, si elle est simple à mettre en œuvre à partir des différents 
modèles décrits au cours du processus de conception, présente de 
nombreuses limitations : 

— elle est non exhaustive (l'ensemble des séquences possible est 
en général infini) ; 

- les zones délicates sont en général bien identifiées par les 
concepteurs mais il est difficile de construire les séquences de test 
amenant le système dans ces zones (qui correspondent souvent à 
la survenue concomitante d'événements rares). De plus, on peut 
ne pas identifier certaines zones sensibles. ; 

- elle est longue : la vitesse de simulation dépend du niveau de 
description du système : le ratio du nombre de cycle simulé par 
seconde (c/s) varie de 1 à 106 selon que le système est décrit au 
niveau porte logique ou transactionnel (TLM) [H 8 000]. 


L'augmentation des garanties nécessite le recours aux 
méthodes formelles pour établir rigoureusement des propriétés du 
système. Il peut s'agir : 

— de propriétés comportementales (sûreté, vivacité) ; 

- de propriétés temporelles (temps de réponse); 

— de limite de consommation. 


On distingue deux approches : la conception sûre et l'intégration 
des méthodes formelles dans le flot standard. 


2. Besoins de garanties 


2.1 Motivations 


La criticité des systèmes embarqués est très variable. Les applica- 
tions relatives au transport de personnes (avionique, ferroviaire, 
automobile intelligente) ou supervisant des procédés industriels 
dangereux (centrale nucléaire, procédé chimique), ou encore médi- 
caux (assistance chirurgicale) doivent offrir des garanties de bon 
fonctionnement, établies par le respect de procédures de conception 
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très strictes et certifiées par des organismes indépendants. Elles doi- 
vent également satisfaire des obligations de robustesse en cas de 
défaillance d'un ou plusieurs éléments de l'application ou de son 
environnement. 


A contrario les applications sur téléphones mobiles n'engagent 
pas la vie humaine comme les cas cités précédemment. Elles 
doivent néanmoins garantir des propriétés de confidentialité, inté- 
grité et disponibilité des données manipulées lorsqu'elles effectuent 
des transactions sur données sensibles (telles les coordonnées ban- 
caires, le paiement des impôts en ligne, le vote électronique). 


Des exemples de bogues retentissants nous rappellent la diffi- 
culté de conception des systèmes embarqués fiables. 


L'explosion lors du premier lancement avec le lanceur Ariane V 
provient originellement de la réutilisation d'une bibliothèque logicielle 
de manipulation de nombres, laquelle était fonctionnelle pour le lan- 
ceur Ariane IV. Cette bibliothèque était utilisée pour traiter les infor- 
mations de vitesse instantanée du lanceur. La vitesse atteinte par le 
lanceur Ariane V était supérieure à celle d'Ariane IV, et n'était pas 
représentable dans le codage des nombres de la bibliothèque ; lors 
du lancement, lorsque la vitesse du lanceur a augmenté jusqu'à ne 
plus être représentable, le logiciel de bord a levé une exception (type 
invalide) qui n'a pas été rattrapée et a induit une suite d'ordres inco- 
hérents menant à l'explosion du lanceur. 


D'autres exemples sont la radiothérapie THERAC 25, dont le dys- 
fonctionnement a causé plusieurs morts, ou le bogue de l'unité d'arith- 
métique flottante du Pentium d'Intel qui a causé des pertes financières 
de plusieurs centaines de millions de dollars à la compagnie. 


2.2 Intégration de la vérification 
dans le flot de conception 


La conception des systèmes embarqués critiques intègre les 
méthodes et outils permettant d'atteindre un degré de criticité 
attendu. Les concepteurs ont défini des procédures de certification 
permettant de qualifier le degré de fiabilité des systèmes conçus. 


À titre d'exemple, les Critères Communs (standard international 
ISO/CEI 15408) utilisés dans le domaine de la sécurité informatique, 
définissent sept degrés d'évaluation du système conçu EAL (Evalu- 
ation Assurance Level), qualifiant le procédé de conception et par là 
même la confiance accordée au système conçu : 

—le niveau EALT, le moins exigeant, correspond à un système 
« testé fonctionnellement » ; 

— le niveau EALA, intermédiaire, correspond à un système « conçu, 
testé et vérifié méthodiquement » ; 

— le niveau EALY7, le plus élevé, correspond à un système dont « la 
conception a été vérifiée de façon formelle et testée ». 


D'autres normes existent, notamment dans le domaine aéronau- 
tique. Les normes D0O-178 (pour les parties logicielles) et DO-254 (pour 
les parties électroniques) identifient cinq niveaux de criticité DAL 
(Design Assurance Level) allant de DAL-E « Un défaut du système ou 
sous-système étudié peut provoquer un problème sans effet sur la 
sécurité du vol » à DAL-A « Un défaut du système ou sous-système 
étudié peut provoquer un problème catastrophique — Sécurité du vol ou 
atterrissage compromis — Crash de l'avion ». Les systèmes soumis à la 
certification DAL-A doivent suivre un plan de conception très strict, et 
permettant de relier les exigences de la spécification avec les 
comportements effectifs du système en cours d'exécution. 


D'autres normes précisent également différents niveaux 


d'exigences (ISO/IEC 26262). 


La construction d'une spécification non ambiguë, d'un modèle 
du système à analyser et l'établissement du lien entre cette spéci- 
fication et les exécutions du système sont les objets des méthodes 
de conception et de vérification formelle. 


Les méthodes formelles sont utilisées de façon distincte selon le 
degré de criticité des systèmes. 
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B Intégration des outils de vérification dans le flot de conception 
existant. C'est l'approche la plus simple. Elle demande peu de 
changements dans les pratiques de conception. Les niveaux d'abs- 
tractions et langages de description restent ceux utilisés par les 
concepteurs, et des passerelles permettent de construire des 
modèles formels à partir des différentes représentations, puis 
d'analyser ces modèles vis-à-vis de la spécification du système, ou 
de comparer les différentes descriptions entre-elles. Ces méthodes 
complémentent la validation traditionnelle par simulation. La 
transformation du modèle de simulation en un modèle formel doit 
être garantie, afin d'assurer que les propriétés vérifiées sur le 
modèle formel sont transposables sur le modèle simulé. La vali- 
dation est effectuée sur le modèle formel et non pas sur le 
système qui sera finalement implanté. 


B Développement de flots de conception sûrs. Le flot de 
conception est entièrement repensé afin de garantir (par preuve) 
que le système produit est conforme à sa spécification initiale. Il y 
a nécessité pour les concepteurs de changer leur pratique pour 
s'intégrer dans l'environnement de développement et preuve, et 
de guider les preuves permettant ultimement de générer du code 
ou des composants matériels dont le comportement est garanti 
conforme aux propriétés énoncées par la spécification. 


Dans le cas de conception de systèmes peu critiques, le flot 
standard est préservé et les outils de vérifications sont greffés sur 
les modèles de conception. Il faut établir des traducteurs automa- 
tiques des modèles de conception vers les modèles formels. La 
vérification est appliquée sur les modèles formels, et les résultats 
de vérification doivent être réinterprétés sur les modèles de 
conception. À contrario, la conception des systèmes requérant un 
niveau d'exigence élevé intègre les modèles formels dans son flot 
de conception. 


La chaîne de conception Scade, utilisée dans l'aéronautique, 
propose des outils de développement, simulation, vérification et 
compilation vers du code exécutable ou des composants matériels à 
partir de spécification formelle. 


L'atelier B utilisé dans le domaine ferroviaire permet également 
d'obtenir du code à partir de spécifications formelles. 


2.3 Différents types de vérification 


On distingue différents types de vérification. 


La vérification de type permet de s'assurer statiquement de la 
cohérence des objets manipulés au sein d'une entité et entre 
différentes entités : on vérifie la bonne adéquation des interfaces 


On s'intéresse dans la suite aux méthodes formelles mises en 
œuvre pour la vérification fonctionnelle. Les autres types de 
vérification sont couverts par des méthodes ad hoc. Dans cer- 
tains cas, les méthodes décrites dans la suite de cet article peu- 
vent être utilisées pour l'analyse de fiabilité et de propriétés 
non fonctionnelles, mais cela reste un usage moins courant. 


3. Méthodes formelles 
pour la vérification 
fonctionnelle 


La vérification formelle des propriétés fonctionnelles d'un 
système consiste, à partir d'un modèle formel décrivant les 
comportements du système et d'un modèle de la spécification 
définissant des gabarits de comportements attendus, à déter- 
miner, par un raisonnement mathématique (éventuellement 
automatisé dans un algorithme lorsque cela est possible) si les 
comportements du modèle du système sont conformes aux 
gabarits définis par la spécification. 


Les différentes approches de vérification fonctionnelles varient 
en fonction : 


- de la nature du modèle à analyser ; 


- de la nature des propriétés à vérifier. 


B Nature du modèle à analyser. Le modèle peut être fini (par 
exemple, un protocole de cohérence de caches étudié pour un 
modèle à 5 caches) ou paramétré (le même protocole étudié pour 
un nombre n de caches, n étant un paramètre). Dans le premier 
cas l'ensemble des états accessibles du modèle est fini et on peut 
construire un algorithme qui les énumère. On se heurte à des 
problèmes d'explosion combinatoire de la taille de cet espace 
d'états. Dans le second cas, l'ensemble des états accessibles n'est 
pas borné et on ne peut pas définir un algorithme général qui par- 
court automatiquement tous les états du système et permette de 
décider de la conformité des séquences du système par rapport à 
la spécification. On peut travailler sur des abstractions finies 
conservatives du modèle initial et retrouver des procédures de 
décision (donc automatisables) ou alors utiliser des méthodes de 
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L e calcul scientifique sur ordinateur se présente principalement sous deux 
aspects différents et complémentaires. 


D'une part, le calcul numérique traditionnel où est exploitée la capacité 
des ordinateurs à effectuer rapidement un grand nombre d'opérations arithmé- 
tiques sur les nombres réels. Les résultats de ce type de calcul sont approchés 
et ils dépendent du choix de la représentation des nombres réels et de la façon 
dont sont effectuées les opérations arithmétiques. L'accumulation des erreurs 
d’arrondis, les problèmes de mauvais conditionnement sont pour les calculs 
numériques des obstacles fréquents à l'obtention de résultats reproductibles et 
fiables. 


D'autre part, le calcul symbolique ou calcul formel consiste à faire effectuer 
par l'ordinateur des calculs mathématiques exacts : développements, transfor- 
mations, simplifications de formules. Un aspect typique du calcul formel est que 
les symboles dans les formules ne sont pas nécessairement remplacés par des 
valeurs numériques particulières mais conservés lors du déroulement des 
calculs. Tous les calculs présentant un caractère d’automatisme, c'est-à-dire dont 
les étapes obéissent à un ensemble bien précis et cohérent de règles, peuvent 
être effectués par ordinateur. Des formules courantes de l'art de l'ingénieur, le 
calcul différentiel et intégral, par exemple, sont ainsi traitées par des programmes 
informatiques avec une fiabilité bien supérieure à celle d’un calcul manuel et 
avec des limites pour la taille des calculs incomparablement plus grandes. 

Le calcul formel est un domaine de recherche en pleine expansion. Dans tous 
les secteurs où les mathématiciens obtiennent des résultats constructifs, de 
nouveaux algorithmes spécifiques sont mis au point, transformés en 
programmes et expérimentés. 
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Un système de calcul formel est un logiciel regroupant des programmes 
de calcul symbolique relatifs à un domaine spécialisé ou bien au contraire des 
programmes assez généraux pour effectuer tous les calculs mathématiques 
usuels de l'ingénieur mathématicien. Un système de calcul formel se présente 
à l'utilisateur sous la forme d'un ensemble de commandes et d’un langage plus 
ou moins élaboré lui permettant d'organiser ses calculs et même quelquefois 
d'étendre le système lui-même. Les systèmes de calcul formel les plus répandus 
contiennent également des programmes numériques et des utilitaires 
graphiques pour faciliter l'interprétation et l'exploitation des résultats. 


1. Notion de système 
de calcul formel 


1.1 Raisons du développement 
du calcul formel 


Dans la mesure où de nombreux calculs peuvent être menés en 
utilisant des procédés ayant un caractère d'automatisme, il est 
logique d'envisager de les faire effectuer par un ordinateur. C'est 
ainsi que les premiers programmes réalisant des calculs symbo- 
liques complexes ont été mis au point dans les années 60 par les 
physiciens théoriciens dans les domaines de la mécanique céleste, 
de la relativité générale et surtout de la physique atomique pour 
l'étude des particules élémentaires. 


L'exemple le plus souvent cité est celui du calcul algébrique des 
éphémérides de la Lune effectué à la main par l'astronome français 
C. Delaunay de 1847 à 1867. Un programme de calcul symbolique 
réalisé en 1970 par A. Deprit, J. Henrard et A. Rom de la société 
Boeing fut capable, en 20 h, de reproduire et de vérifier l'ensemble 
des calculs de Delaunay [1]. 


Les concepteurs de ces programmes se sont rendus compte très 
vite que leurs performances reposaient sur une bonne réalisation 
des objets de base, par exemple des polynômes. Les algorithmes 
mis en œuvre sont alors susceptibles de constituer le cœur d'un 
programme de calcul formel intéressant non seulement les 
chercheurs d'une discipline spécialisée mais aussi tout ingénieur ou 
chercheur amené dans sa pratique quotidienne à faire du calcul 
symbolique. Les possibilités de ces programmes se sont étendues 
à tous les domaines où l'algèbre a obtenu des résultats constructifs. 
De manière à permettre à l'utilisateur d'écrire ses propres fonctions 
et ses propres programmes, un langage de haut niveau et de syntaxe 
aisée est généralement adjoint à l'ensemble des programmes, ainsi 
qu'une interface avec le système d'exploitation de la machine hôte 
et ses programmes de base, éditeur, gestion des fichiers par 
exemple. 


On peut donc définir un système de calcul formel comme un 
ensemble de programmes caractérisé par la présence : 


— de modules de manipulations d'expressions algébriques 
(comme les polynômes), et réalisant des opérations pour lesquelles 
des algorithmes efficients ont été découverts (comme la factorisation 
des polynômes) ; 

— de commandes pour définir l'environnement de calcul et 
réaliser l'interface avec d'autres programmes de l'ordinateur ; 

— d'un langage de haut niveau pour la définition des fonctions 
et des programmes propres à l'utilisateur (pour une définition 
précise des notions de langage et de langage de haut niveau, le 
lecteur pourra se reporter à l'article Langages de programmation. 
Introduction [H 2 000] de ce traité). 
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Un système de calcul formel peut offrir un mode de traitement 
par lot, c'est-à-dire qu’un ensemble de calculs est effectué en 
séquence sans intervention de l'utilisateur, ou un mode interactif et, 
dans ce cas, la main est rendue à l'utilisateur après chaque calcul 
et celui-ci peut intervenir sur le déroulement des opérations. 


Ouelques-uns des systèmes les plus répandus seront présentés 
dans le paragraphe 3. Les raisons pour lesquelles les systèmes de 
calcul formel ont connu un développement accéléré depuis les 
années 60 sont de plusieurs ordres. 


: Une raison essentielle tient à une caractéristique du calcul symbo- 
lique. Contrairement aux calculs numériques, il n'est généralement 
pas possible de prévoir, pour l'exécution d'un calcul symbolique 
particulier, son temps d'exécution et l'espace en mémoire nécessaire 
pour son déroulement et même pour l'expression du résultat. Ce 
phénomène est couramment appelé l'explosion des calculs 
intermédiaires : on le rencontre par exemple dans les algorithmes de 
résolution des systèmes d'équations algébriques non linéaires. 
L'évaluation de la taille et du temps des calculs d'un algorithme est 
l'étude de sa complexité. Des progrès importants dans l'étude de la 
complexité des algorithmes et surtout la découverte d'algorithmes 
nouveaux plus performants ont beaucoup contribué à l'extension du 
calcul symbolique sur machine. 


: La plupart des premiers grands systèmes de calcul formel ont été 
écrits en Lisp : un environnement de programmation adapté est en 
effet devenu disponible, grâce à une meilleure connaissance des 
possibilités des langages de la famille des Lisp (voir par exemple 
l'article Lisp [H 2 520] de ce traité). 


: Des résultats inaccessibles auparavant et des résultats originaux 
obtenus par des programmes spécialisés de calcul symbolique 
constituent une puissante motivation à son utilisation dans de 
nombreux domaines de recherche [1]. 


: Enfin et surtout, les calculs longs et fastidieux menés à la main 
pour exploiter les formules d'un modèle sont pratique courante dans 
presque tous les domaines de recherche et de développement. De 
manière à éviter les risques d'erreurs dans les diverses étapes des 
calculs comme les développements, les simplifications ou l'écriture 
de programmes numériques résultants, le recours au calcul formel 
se généralise. La demande devient donc très forte de systèmes de 
calcul formel généraux, fiables et extensibles. 


1.2 Possibilités et critères d'évaluation 


Il est possible de classer les systèmes de calcul formel en trois 
grandes catégories. 


: Les systèmes spécialisés conçus et réalisés pour un domaine 
spécifique et restreint d'applications : les chercheurs de disciplines 
telles que la physique des hautes énergies, la mécanique céleste et 
la relativité générale utilisent depuis longtemps le calcul symbolique 
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pour découvrir et exploiter les propriétés de leurs modèles. Ils sont 
même sans doute les premiers à avoir développé des systèmes de 
calcul symbolique de taille importante et ils continuent à le faire. Le 
système Reduce, qui fait partie de la catégorie suivante, trouve son 
origine dans un système développé par A.C. Hearn pour des applica- 
tions en physique théorique. Les systèmes spécialisés sont parmi les 
plus efficaces en termes de rapidité et de taille des problèmes 
traitables. Cependant des difficultés se présentent pour leur dévelop- 
pement, leur maintenance, leur fiabilité et leur extension. 


: Les systèmes à large spectre ou généralistes : les principaux sont 
Reduce, Macsyma, Maple, Mathematica et Axiom. Ces systèmes 
s'adressent à un utilisateur inconnu : ils sont gourmands en temps 
et en occupation de mémoire, mais les progrès en puissance des 
ordinateurs centraux et surtout des stations de travail et des ordina- 
teurs individuels en ont rendu l'utilisation courante. C'est la sécurité 
de leur utilisation qui les conduit à concurrencer les systèmes 
spécialisés. 

- Enfin, les petits systèmes (comme Derive) qui tournent sur 
micro-ordinateur ou même sur calculatrice de poche (la HP-95 de 
Hewlett-Packard) : ils ne peuvent traiter que les problèmes de petite 
taille, mais sont utilisés dans l'enseignement comme support de 
nombreuses expériences pédagogiques. 


L'apprentissage d'un système de calcul formel représente un 
investissement en temps, aussi est-il conseillé, avant de porter son 
choix sur un système particulier, de retenir quelques critères 
d'évaluation de la qualité des divers systèmes. Ne sont concernés 
par cette liste que les langages à large spectre. 


e La richesse de la bibliothèque d’algorithmes : il s'agit véritable- 
ment de ce que le système est capable de faire. Les algorithmes 
implémentés sont-ils efficaces et reflètent-ils l'état de l'art ? Les 
domaines principaux suivants sont couverts par presque tous les 
systèmes : 

— arithmétique sur les entiers et les rationnels en précision 
pratiquement illimitée ; 

— nombres réels de précision fixée mais arbitrairement grande 
et bibliothèque de fonctions spéciales ; 

— algèbre sur les polynômes à une ou plusieurs indéterminées, 
à coefficients dans l'ensemble des entiers où dans les corps finis ; 
factorisation de ces polynômes ; 

— algèbre linéaire: calcul matriciel, résolution de systèmes 
d'équations linéaires ; 

— résolution de systèmes d'équations algébriques non linéaires ; 

— analyse classique sur les fonctions : fonctions élémentaires (tri- 
gonométriques, trigonométriques inverses, exponentielles et loga- 
rithmes), calcul de dérivées, calcul de primitives, d'intégrales 
définies, de limites, mais également développements limités et en 
séries. 
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e L'interface graphique : la visualisation des courbes et des sur- 
faces est une aide à une meilleure compréhension des résultats 
obtenus. Les graphiques et les images peuvent contribuer à la lisi- 
bilité d'un document scientifique : il est pratique de pouvoir les créer 
directement depuis le système de calcul formel. 


e La documentation : il s’agit non seulement d'un manuel de réfé- 
rence du langage de calcul formel, mais aussi de manuels intro- 
ductifs, développant de nombreux exemples, et, sans se cantonner 
à la description de la syntaxe du langage, proposant une approche 
stylistique pour la programmation. La documentation doit s'adresser 
à deux catégories d'utilisateurs : certes ceux dont le domaine de 
spécialité est le calcul formel, mais aussi ceux qui s’en servent 
comme d’un outil de calcul scientifique parmi d'autres. 


e Les possibilités d'extension : il existe deux façons de se servir 
d’un système de calcul formel. La première pourrait s'appeler mode 
super-calculette ou mode interprété : l'utilisateur effectue un calcul 
ou une série de calculs en interaction avec le système. Mais une 
seconde façon consiste à introduire de nouvelles fonctionnalités 
dans le système correspondant à un champ particulier d'applica- 
tions. Le système offre-t-il la possibilité de construire de nouveaux 
modules fonctionnant avec autant d'efficacité que les modules du 
système de base ? 


Des éléments d'appréciation sur les qualités respectives des 
systèmes existants ont davantage de poids lorsqu'ils sont donnés 
par les utilisateurs chevronnés que par les entreprises qui commer- 
cialisent les produits. 


Les calculs qui suivent ont été effectués à l’aide du système 
Axiom [2]. Ils peuvent très facilement être réalisés avec les autres 
systèmes. Un tout petit nombre d'explications est suffisant pour 
comprendre la syntaxe. 


- Tout objet dans Axiom a un nom, un type et une valeur. Le 
symbole : réalise l'attribution de type (le typage) et le 
symbole := l'attribution de valeur. Ainsi, après l'exécution de a: 
Integer := 5, a représente un entier de valeur 5. 


Lorsqu'une évaluation est demandée, Axiom retourne la valeur du 
résultat et son type. Une commande d'environnement permet de 
demander la suppression de l'impression du type du résultat : c'est 
le cas dans ces exemples. Lorsqu'une demande d'évaluation se 
termine par ; , le résultat de cette évaluation n'est pas affiché à 
l'écran : il s’agit d'un calcul intermédiaire. 


ES CU CU 


La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 
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L: conception assistée par ordinateur (CAO) est aujourd'hui d'un usage cou- 
rant et certains sont tentés d'affirmer que cette technologie a atteint sa matu- 
rité. Pourtant, il est facile de se convaincre qu'il n'en est rien et que les évolutions 
en cours vont bouleverser considérablement la CAO et, par voie de consé- 
quence, son utilisation. Pour montrer cette évolution, nous présentons dans ce 
premier article les aspects les mieux maîtrisés dans les systèmes actuels. Ils 
concernent essentiellement la partie géométrique des modèles utilisés en CAO. 
Pour situer le domaine de l'article, nous commençons par les définitions indis- 
pensables et un historique illustrant l'influence des choix effectués sur la techno- 
logie actuelle. Pour montrer la quintessence et les implications sur les systèmes 
du marché des modèles utilisés en CAO, nous en donnons les éléments essen- 
tiels, aussi bien sur l'architecture générale (notions de modèle et de multimo- 
dèle), que sur les principes fondamentaux (modèles géométriques solides, 
surfaciques et paramétriques). 

Dans un second article [H 3 752], nous montrerons que, bien qu'encore en 
pleine mutation, de nouvelles méthodes apparaissent et conduisent vers des 
systèmes prenant de mieux en mieux en compte les aspects fonctionnels. 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie est strictement interdite. 


© Techniques de l'Ingénieur, traité Informatique H 3750-11 


75 


Référence Internet 


H3750 


CAO : MODÉLISATION GÉOMÉTRIQUE 


1. Objectif 


Si nous insistons tout particulièrement sur la modélisation, 
c'est que l'objectif de la CAO est la création d'un modèle 
(maquette virtuelle) ayant les deux propriétés suivantes : 

— il doit représenter les propriétés de l'objet (au sens large) ; 

— il doit être exploitable (calculs, simulations, préparation 
des gammes, etc.). 


Nota : il est indispensable de disposer, bien entendu, de moyens matériels (ordinateur, 
écran, etc.), sur lesquels nous ne reviendrons pas, leurs caractéristiques étant bien connues. 

L'architecture générale d'un système de CAO est présentée 
figure 1. 


L'interface homme-machine revêt une importance fondamentale, 
aussi bien en entrée (Econc), qu'en sortie (Sconc). En entrée, il s’agit 
essentiellement de : 


— donner des valeurs (rayon d'un cercle, distance entre deux 
entités, etc.) ; 


— entrer des positions (en deux ou en trois dimensions) ; 
— choisir une action (menus) ; 


— identifier une entité (montrer un objet pour le modifier ou le 
déplacer, etc.). 


En sortie, on s'appuie en général sur la visualisation des objets 
soit sous une forme habituelle (perspective, vue de face, etc.), soit, 
comme nous le verrons plus loin (8 4.3), en montrant l'arborescence 
de conception. 


On peut également disposer de données issues par exemple de la 
numérisation d'une forme existante (Eauto). Enfin, on cherche à 
déterminer automatiquement des sorties telles que les programmes 
d'une machine à commande numérique ou d'un robot (Sauto). 


Pour mettre en œuvre la maquette virtuelle, le système de CAO 
gère des modèles et des connaissances. Les modèles sont des 
représentations d'objets existants ou en cours de conception. Ils 
sont divers : bibliothèques de visserie, avion, outillage, etc. Les con- 
naissances représentent ce que peut connaître le système de CFAO 
du mode de conception ou de l'organisation des données. Elles peu- 
vent être partiellement incluses dans des modèles (historique de 
conception d'une pièce) ou être plus générales (algorithmes, systè- 
mes experts, etc.). 


Opérateur 


Econc 


Eauto | Sauto 


Modèles 
Connaissances 
etc. 


Figure 1 - Architecture générale 
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Sigles et définitions 


Comme la plupart des nouvelles technologies, tout ce qui gra- 
vite autour de la CAO comporte de nombreux sigles ou acronymes 
qu'il est intéressant de connaître avant d'entrer dans les détails de 
leur signification. 


Le sigle CAO, pour conception assistée par ordinateur (CAD : 
Computer Aided Design), désigne généralement les outils pour 
les premières phases de développement d'un produit, tout par- 
ticulièrement les activités des bureaux d'études. Dans la suite de 
cet article, nous lui donnerons une emprise plus large en consi- 
dérant que c'est le système de CAO qui contient les informa- 
tions indispensables aux opérations de calcul ou de fabrication. 


La CFAO, conception et fabrication assistées par ordinateur 
(CAD/CAM : Computer Aided Design/Computer Aided Manufac- 
turing), recouvre l'ensemble des phases de conception et de 
fabrication. 


Le sigle IAO, ingénierie assistée par ordinateur (CAE : Compu- 
ter Aided Engineering), est le plus souvent associé à la notion 
de calcul et de simulation. Il fait référence aux approches qui 
lient les modèles de CAO aux modèles de calcul pour conduire 
à une conception guidée par la simulation. 


Plusieurs sigles sont utilisés dans le cadre de la CAO sans 
qu'ils méritent une explication détaillée dans ce premier article : 
CN (NC : Numerical Command) pour commande numérique, 
SGBD (DBMS : Data Base Management System) pour système 
de gestion de base de données, SGDT (PDMS : Product Data 
Management System) pour système de gestion de données 
techniques, prototypage rapide (rapid prototyping) pour les 
méthodes permettant d'obtenir rapidement une maquette de 
l'objet ou un outillage, ingénierie simultanée (concurrent engi- 
neering) pour les méthodes de travail où tous les corps de 
métiers peuvent intervenir en même temps, etc. 


2. Modélisation 


2.1 Notion de modèle 


La notion de modèle est bien connue depuis l'Antiquité, soit sous 
forme de maquette physique (principe encore utilisé aujourd'hui), 
soit sous forme d'objets abstraits (mathématiques le plus souvent), 
ces derniers pouvant être adaptés pour aboutir à un prototype infor- 
matique respectant un certain nombre de propriétés. Nous nous 
intéressons essentiellement à la représentation de la morphologie 
des objets. 


L'étude de la représentation des objets implique d'analyser les 
deux aspects fondamentaux de toute modélisation : 


— la représentation des caractéristiques (par exemple, géométriques) 
des objets. Elle peut se faire soit sous une forme explicite, soit sous une 
forme implicite ; 


— la mise en œuvre d'opérations, par exemple des opérations de 
composition ou de modification de solides. En effet, l'objectif de la 
modélisation est de constituer une représentation des objets qui soit 
utilisable pour la simulation. La visualisation est une simulation parti- 
culière du modèle ; de même, le dialogue, le calcul massique ou le 
calcul de structures peuvent être considérés comme des simulations, 
même si, très souvent, leur mise en œuvre nécessite la constitution 
d'un modèle adapté (modèle applicatif), à partir du modèle géométri- 
que existant, et d'autres informations liées au type de traitement à 
appliquer (par exemple, un modèle par éléments finis). 
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Historique 


L'histoire de la CAO est intéressante car sa connaissance permet de 
comprendre un certain nombre d’évolutions. Les quelques éléments qui sui- 
vent n'ont d'autre but que de montrer que les techniques utilisées aujourd'hui 
et les stratégies de certains fournisseurs ne sont pas sans rapport avec une 
histoire courte, mais riche et mouvementée. Il est d’ailleurs évident que, 
contrairement à certaines affirmations, cette évolution est loin d’avoir atteint 
son terme ; au contraire, on ne peut qu'encourager les acteurs de ce domaine 
à redoubler d'efforts. 


Même si l'interface homme-machine n'est pas l'objet de cet article, on peut 
noter l'influence déterminante des travaux de Sutherland (Sketchpad, 1963) 
et de l'apparition des premiers terminaux graphiques (en particulier d'IBM, 
avec le DAC au début des années 1960 et le 2250 dans la seconde moitié de la 
même décennie). 


L'un des aspects les plus fondamentaux dans l'avènement de la CAO est 
sans doute le fait que des approches très différentes aient vu le jour pour 
représenter les surfaces d'une part et les solides d'autre part. La prise en 
compte des surfaces gauches s'est surtout faite chez de grands utilisateurs 
(automobile, aéronautique), en particulier pour des contraintes de com- 
mande numérique. Les travaux dans le domaine de l'automobile par Coons 
(Ford), Bézier (Renault), De Casteljau (Citroën) et d'autres sont encore à la 
base des systèmes d'aujourd'hui. Des développements, à l'Aérospatiale ou 
chez Dassault, allaient conduire à des systèmes commercialisés par la suite 
(STRIM, CATIA, etc.). Tous ces travaux se sont développés sur des bases 
mathématiques globalement semblables. 


Les premières tentatives pour représenter des solides sont consécutives à 
des problèmes qui n'étaient pas directement liés à la CAO (ce terme n'était 
pratiquement pas employé à l'époque), mais à des contraintes spécifiques. 
Parmi les premiers systèmes basés sur la modélisation des solides, on peut 
citer, dès le milieu des années 1970, EUCLID en France (CNRS) et EUKLID en 
Suisse. La motivation de concepteurs d'EUCLID se trouvait dans la nécessité 
de disposer d'une maquette virtuelle pour traiter des problèmes de soufflerie. 
La prise en compte de ces modèles a été relativement expérimentale sans dis- 
poser d'une base mathématique importante. 


Aux États-Unis ont été lancées un certain nombre d'études, alors même que 
les systèmes, dits « clés en main », qui en provenaient ont conservé très long- 
temps (y compris au début des années 1980) une approche «fil de fer ». 
Commercialement, ont émergé quelques sociétés fournissant des systèmes 
clés en main, comme Computervision ou Applicon. Le principal projet universi- 
taire était connu sous le terme de PADL, et il reste indiscutablement l'approche 
la plus formalisée de la modélisation des solides par leur historique de 
construction. || a conduit à des systèmes industriels, parmi lesquels GMSOLID 
(General Motors). D'autres développements, bien que moins avancés du point 
de vue de la formalisation, ont conduit à des implantations dans de nombreux 
systèmes industriels. Le Japon a vu se développer, essentiellement dans le 
cadre universitaire, des modèles de solides, comme GEOMAP ou TIPS. Enfin, 
des projets autour de la modélisation des solides, comme COMPAC ou ROMU- 
LUS, se sont affirmés très tôt en Europe. 


L'influence française sur l'histoire, et par voie de conséquence sur les sys- 
tèmes actuels, est non négligeable, aussi bien en modélisation des surfaces 
avec les travaux de De Casteljau chez Citroën, de Bézier chez Renault (débou- 
chant sur UNISUREF, puis intégré à EUCLID-IS), de Massabo à la SNIAS un peu 
plus tard (SDS, puis SYSTRID, puis STRIM) ou des travaux aux avions Marcel 
Dassault (Bernard, Neuve-Église), qui à partir de DRAPO aboutiront à CATIA, 
qu'en modélisation des solides, avec EUCLID. On constate des approches dif- 
férentes selon la culture des entreprises : les premières études menées chez 
Citroën (sur le capot de la 2 CV !) cherchaient essentiellement à mieux utiliser 
les machines à CN. À l'opposé, Dassault a mis en place une stratégie ambi- 
tieuse qui consistait à modéliser entièrement un avion : le système réalisé au 
début en utilisant des composants du marché (CADAM par exemple) s'est 
peu à peu développé pour aboutir au système CATIA et à la création d'une 
filiale dédiée (Dassault Systèmes). 


De nombreuses sociétés ont également contribué au développement de la 
CFAO. Ne cherchant pas à être exhaustif et pour ne pas être en situation 
d'oublier des acteurs prestigieux, nous conseillons pour plus de détails 
l'ouvrage de Poitou [1]. Citons cependant quelques exemples significatifs. 


Un certain nombre d'éléments développés chez Citroën ou Peugeot ont été 
intégrés au début des années 1980 à CADDS de Computervision. Cet apport a 
été non négligeable dans la mesure où les fondements des modèles utilisés (en 
particulier sur les aspects mathématiques et algorithmiques) sont toujours 
d'actualité. 


Des sociétés de taille moins importante ont participé directement ou indi- 
rectement au développement de la CAO : Merlin Gérin, à travers MECAN, a 
facilité le développement de GRI2D, à la base des systèmes de ESIA (CADGRI, 
MICROPROTOL). 


Quelques remarques issues de cet historique peuvent éclairer l'utilisateur 
de la CAO aujourd'hui. 


Les travaux sur les surfaces se sont longtemps développés de manière tota- 
lement indépendante de ceux sur les solides. En réalité, ces deux approches 
répondaient à deux grandes catégories de problèmes et ont fait appel à des 
méthodes de résolution très différentes (mathématique pour les surfaces, 
structure de données pour les solides). Ces divergences dans les approches 
solide et surface ne sont pas sans conséquence sur les difficultés rencontrées 
à les intégrer dans un modèle unique. 


Des systèmes, dont la vocation « pragmatique » (au sens où ces systèmes 
étaient directement utilisables en bureaux d'études, sans remettre en cause 
les méthodes de travail) était évidente, ont été développés à la fin des années 
1970. Plus particulièrement orientés vers le 2D (ou le 2D-1/2), ces projets ont 
conduit à des systèmes tels que CADAM (Lockheed). 


Certaines approches ont privilégié des modeleurs spécifiques à un système 
(c'est le cas du modeleur de CATIA par exemple) alors que d'autres se sont 
orientées vers des modeleurs génériques (par exemple, ROMULUS, puis 
Parasolid et Acis). 


Des méthodes, aujourd'hui très à la mode (conception paramétrique, géo- 
métrie variationnelle), étaient déjà présentées dans plusieurs travaux dès le 
début des années 1980 et sont intégrées maintenant à la plupart des systèmes 
commercialisés. Il faut du temps entre l'émergence des idées et leur intégra- 
tion réelle dans des produits commercialisés (l'évolution de la puissance et de 
la convivialité des matériels a également son importance). Les travaux actuels 
sur la prise en compte des fonctions ou des approches différentes du dialogue 
homme-machine seront sans doute implantés dans les systèmes commer- 
ciaux dans quelques années. 


Il faut se souvenir qu'au début des années 1990 , les systèmes de CFAO 
étaient implantés sur de « mini » ou de « gros » ordinateurs et des terminaux 
connectés à des vitesses de quelques milliers de bauds, à de rares exceptions 
près. La puissance partagée était trop faible pour un fonctionnement correct, 
dès que des opérations un peu coûteuses en calcul étaient demandées. Les 
connexions en asynchrone imposaient une interactivité de bas niveau. 


À la fin des années 1990, la CFAO est largement répandue, à travers les sta- 
tions de travail ou les micro-ordinateurs. Elle reste cependant essentiellement 
basée sur la géométrie. À partir de cette décennie, apparaissent quelques élé- 
ments nouveaux : l'industrialisation des approches paramétriques et la prise 
en compte d'éléments de sémantique un peu plus élevée, tentant de repré- 
senter une information ayant une signification pour l'utilisateur (par exemple, 
un trou est défini en tant que tel et non plus comme une différence boo- 
léenne). Ces notions d'éléments caractéristiques, ou entités (features), 
demeurent cependant très proches de la géométrie. Enfin, apparaît, à la fin 
des années 1990, la nécessité de prendre en compte non seulement le 
modèle du produit, mais également le process qui permettra de le fabriquer 
et de le maintenir. 


La représentation informatique nécessite un certain nombre de 
structures algorithmiques ou de données. Pour connaître leurs pro- 
priétés, la meilleure solution est de disposer d'un modèle mathéma- 
tique, représentant de manière abstraite des classes d'objets et les 
opérations qui leur sont applicables. À supposer que l'on sache 
déterminer un modèle mathématique, il reste à effectuer le passage 
du modèle mathématique au modèle informatique. 


Soit une représentation informatique E, composée d'un ensemble 
de représentations syntaxiquement correctes. On définit une rela- 
tion s de M (espace mathématique) dans E. Le domaine de s est 
noté D et l’image de D par s est notée I. 

On a: 


DcM : tous les objets ne sont pas modélisables dans la représen- 
tation mathématique définie ; 
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ICE : toutes les représentations syntaxiquement correctes dans E 
ne sont pas forcément valides. 


On définit les qualités du modèle informatique : 

— une représentation r de I est non ambiguë si elle correspond à 
un seul objet ; 

— une représentation r de I est unique si l'objet correspondant 
n'admet pas d'autre représentation que r, c'est-à-dire s(s-l(r)) = r. 
Le modèle I est unique si tous ses éléments sont uniques ; 

— une représentation est valide si elle appartient à I. La solution 
la plus simple pour assurer la validité est que toutes les représenta- 


tions syntaxiquement correctes soient valides (I=E). 


De nombreux modèles informatiques sont possibles. Se pose 
alors le problème de la cohérence entre ces modèles. On dira que 
deux relations de représentations s et s’sont équivalentes si chaque 
image par s possède un équivalent r’ par s’,etret r’ sont équivalents 
s'ils représentent le même ensemble d'objets dans M. 


Deux relations de représentation non ambiguës sont équivalentes 
si et seulement si elles ont le même domaine. 


Deux représentations r et r’ sont cohérentes s'il existe au moins 
un objet m de M tel que s(m)= r et s’(m)= r’. Si les modèles ne 
sont pas uniques, m peut avoir plusieurs images dans E et E’. Siles 
modèles sont ambigus, d'autres éléments de M peuvent avoir pour 
images r et r’. 


Considérons, par exemple, un modèle ambigu, qui représenterait 
un solide par des vues de face et de dessus. Il est fondamental 
d'assurer la cohérence entre ces vues. Ces deux représentations ne 
doivent cependant pas être équivalentes, ce qui tendrait à affirmer 
que deux objets ayant la même vue de dessus sont identiques. 


En admettant que l'on soit capable de définir les relations propo- 
sées précédemment, il faut tenir compte, également, d’un certain 
nombre de qualités que l’on peut exiger d'un modèle informatique. 


B Concision : cette notion, difficile à définir de manière précise, est 
mesurée par la quantité d'informations nécessaire pour représenter 
un objet. Elle n'est cependant pas totalement indépendante des trai- 
tements que l'on appliquera sur les modèles : une certaine redon- 
dance des informations sera ainsi souvent utile pour l'efficacité, voire 
l’applicabilité, de certains algorithmes. On verra que l'on peut ainsi 
conserver dans un modèle B-Rep (8 4.2) les relations topologiques 
face(arête) et arête(sommet), plutôt que simplement face(sommet), 
dans la mesure où cette dernière ne donne pas directement les 
arêtes, pourtant souvent utilisées, par exemple, dans une visualisa- 
tion de type filaire. De même, dans des modèles plus complets, on 
manipule souvent des informations de type arête(face), donnant les 
faces adjacentes à une arête donnée (avec des informations complé- 
mentaires, permettant de connaître le degré de continuité en cette 
arête, c'est-à-dire la continuité en tangence des deux faces). 


B Facilité de mise en œuvre d'algorithmes : cette qualité est liée 
aux algorithmes que l'on souhaite mettre en œuvre. Il est évident 
que certains modèles facilitent la réalisation de certaines opérations 
et d’autres non. Par exemple, les opérations booléennes sont assez 
compliquées à implémenter sur un modèle B-Rep (8 4.2), alors que 
leur application à un modèle par boîtes (8 4.1) est triviale. Le résultat 
n'a cependant pas les mêmes propriétés dans les deux cas,etonne 
peut donc pas choisir la facilité, sans tenir compte des propriétés 
des modèles obtenus. 


B Ouverture : cette qualité n’a pas d'influence réelle sur le passage 
du modèle mathématique au modèle informatique. Bien qu'elle soit 
spécifique au modèle informatique, son importance est fondamen- 
tale. Elle est complémentaire des facilités de mise en œuvre d'algo- 
rithmes. 


La mise en œuvre des modèles n'est pas toujours obtenue direc- 
tement par passage d'un modèle mathématique à un modèle infor- 
matique. Même lorsqu'un modèle mathématique existe, un certain 
nombre de caractéristiques liées à l'informatique impliquent des 
limitations importantes dans ce passage. La caractéristique essen- 
tielle qu'il faut retenir est la notion de tolérance informatique. 
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Les réels sont représentés en machine avec un certain nombre de 
chiffres significatifs, ce qui induit une erreur qui peut devenir non 
négligeable en fonction des calculs effectués. 


Exemple : si on utilise des réels codés sur trois chiffres (ce qui est 
bien entendu éloigné de la réalité, mais qui ne retire rien à la généralité 
tout en simplifiant la présentation), on peut effectuer les opérations 
suivantes : 


A = 2,05 

B = A/2= 1,02 (approximation sur trois chiffres) 

C=2 B = 2,04 

On devrait bien entendu retrouver À. On voit d'ailleurs bien dans cet 


exemple très simple l'intérêt de l'utilisation de systèmes de calcul for- 
mel, permettant de travailler le plus longtemps possible en symbolique. 


Certaines propriétés mathématiques peuvent ne plus être vérifiées. 


Exemple : considérons un codage des nombres compris entre 


107% et 10% et l'expression suivante : 


D = A(B+1/A-B) en supposant que le compilateur ne fait pas 
d'optimisation, c'est-à-dire aucun calcul formel éliminant le terme B. 


Donnons à À la valeur 1042 et a B la valeur 1. Comme 1/A est très 


petit, B+1/A donnera B et l'expression sera égale à O alors qu'elle 
devrait être égale à 1 | 


Les problèmes liés à l'approximation sont de toute évidence sour- 
ces d'inconvénients très importants dans les systèmes de CAO. Bien 
que de nombreux travaux tentent de les prendre en compte, il suffit 
pour la suite de cet article de savoir qu'il n'existe pas de solution uni- 
verselle et que les retombées de cet inconvénient dans les modèles 
et les opérations intégrés dans les systèmes actuels demeurent 
importantes. Nous en citerons quelques exemples au fur et à mesure 
de la présentation des différentes approches. 


On peut, pour conclure sur les liaisons entre modèle mathématique 
et modèle informatique, considérer les cas suivants : 


— il n'existe pas de modèle mathématique complet : le modèle 
informatique répond à un certain nombre de recettes ou 
d'approximations ; 

— il existe un modèle mathématique inapplicable du point de vue 
de l'informatique : on revient au cas précédent ; 

— il existe un modèle mathématique que l'on peut transporter en 
informatique : les avantages et les inconvénients du modèle infor- 
matique sont ceux du modèle mathématique et ceux liés à l’informa- 
tique en général (en particulier, ceux liés à la tolérance informatique 
illlustrée précédemment). 


Ouels que soient les choix effectués, il demeure que tout modèle 
ne sera qu'une approximation de la réalité et que tout utilisateur de 
CAO doit avoir un minimum de connaissance sur les concepts et les 
modèles utilisés sous peine de connaître des désagréments. 


2.2 Multimodélisation 


Il est illusoire de croire que les systèmes de CAO peuvent être 
basés sur un modèle central qui contiendrait les informations défi- 
nissant sans ambiguïté les objets. En effet, on s'aperçoit rapidement 
que l'on se heurte au problème classique (bien connu dans les sys- 
tèmes de gestion de bases de données) de vues multiples adaptées 
à chaque utilisateur, être humain ou programme. 


Ainsi, par exemple, au sein de la même entreprise, le P.-D.G. le 
concepteur, le responsable des achats et le responsable de la fabrica- 
tion n'ont pas la même façon d'appréhender les objets. Dans des 
entreprises différentes (donneur d'ordre/sous-traitant, par exemple), 
les cultures peuvent encore amplifier les différences. Lorsque l'on 
observe le fonctionnement d'un système de CAO (ou d'IAO), on note 
très rapidement des concepts et des méthodes variant fortement d'un 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie est strictement interdite. 
© Techniques de l'Ingénieur, traité Informatique 


Référence Internet 


H3750 


CAO : MODÉLISATION GÉOMÉTRIQUE 


logiciel à un autre : par exemple, le logiciel de CAO est fondé sur un 
modèle mathématique pour les surfaces, alors que le modèle de cal- 
cul utilise une approximation par des triangles. 


Ces contraintes conduisent à un ensemble de modèles (multimo- 
délisation) dont les objectifs et les domaines d'application peuvent 
être fonction du domaine pris en compte, de l'utilisateur (opérateur 
ou programme), voire même être spécialement définis pour amélio- 
rer les performances. Cet aspect est encore amplifié lorsque l'on 
considère toutes les activités de l’entreprise. En effet, la cohérence 
de l’ensemble et l'assurance que toutes les modifications ou toutes 
les évolutions sont correctement propagées devient un problème 
extrêmement complexe à résoudre. 


3. Modélisation géométrique 


3.1 Familles de modèles 


Le modèle géométrique est au cœur du système de CFAO. C'est 
lui qui contient l'ensemble des informations géométriques sur les 
objets. La puissance d'un système de CFAO est en grande partie liée 
à la qualité (ou aux qualités) de son modèle géométrique. Bien que 
ce modèle soit encore insuffisant, il est indispensable de bien 
appréhender les avantages et les inconvénients de chaque famille. 


B Modèles bidimensionnels (2D) 


Ils ont une connaissance des objets limitée à des vues planes, sans 
relation, sauf outils particuliers, entre elles. Ils sont bien adaptés au 
dessin industriel. Certains outils (de type trait de rappel) peuvent facili- 
ter des relations partielles entre vues. Ils peuvent être enrichis par des 
outils de construction « simples » d'objets 3D, comme l'extrusion ou la 
révolution (certains parlent alors de 2D-1/2). Ils ne demeurent impor- 
tants aujourd'hui que parce qu'ils sont utiles pour la construction 
d'objets 3D et parce qu'ils servent de base à une partie de la cotation. 


B Modèles tridimensionnels (3D) 
e Modèles fil de fer (wireframe) 


Un objet est connu par ses sommets et les arêtes qui les joignent. 
Ces modèles sont maintenant abandonnés et ne méritent pas que 
l'on s'y attarde. 


Nota : il ne faut pas confondre modèle fil de fer avec vue en « filaire » ou « au trait », qui 
est la représentation de n'importe quel type de modèle avec des traits (par opposition à des 
images de synthèse). 


e Modèles surfaciques 
Les surfaces d'un objet sont connues, mais pas la matière. Ces 


modèles sont essentiellement basés sur des équations paramétriques. 
Leurs fanndements restent très imnartants dans la mesure aïr ils sont 


3.2 Bases des modèles de solides 


Un solide respecte les conditions suivantes : 

— rigidité : un solide a une forme invariante, quelles que soient sa 
position et son orientation (les distances et les angles algébriques 
sont conservés) ; 

— finitude : un solide occupe une portion finie de l'espace ; 

— homogénéité : un solide a un intérieur, considéré comme 
homogène ; 

— un point de l’espace ne peut appartenir qu'à un solide au plus. 

Un modèle de solides, qu'il soit mathématique ou informatique, 
doit également respecter des conditions sur les classes représentables 
et les opérations applicables, en particulier : 

— validité : tout modèle constructible doit correspondre à un 
solide ; 

— puissance : tout objet doit être représentable. 


D'après [2], les modèles de solides sont des classes de congru- 


3 : à ie ts ; 
ence de sous-ensembles de E°, bornés, fermés, réguliers et semi- 
analytiques. Une classe de congruence est la collection de sous- 


ensembles de E° qui peuvent être obtenus l’un de l'autre par des 
séquences de rotations et de translations. 


Les solides étant caractérisés, un modèle doit respecter les condi- 
tions de validité exprimées dans les caractéristiques générales des 
modèles. Toute opération sur des solides doit être une loi de compo- 
sition interne dans l'ensemble des solides mathématiques. Ainsi, par 
exemple, les opérations booléennes « classiques » ne respectent pas 
cette condition. En effet, il est facile de montrer [3] que la propriété 
« régulier » (fermeture de l'intérieur différente de l'ensemble vide) 
n'est pas respectée. La figure 2 montre que le résultat qui pourrait 
être obtenu par l'opération booléenne intersection entre deux objets 
tangents par une face pourrait être non vide (portion de face). Le 
résultat n’est plus un solide (l'opération n'est pas interne). 


Ilest donc nécessaire de définir des opérations booléennes dites 
régularisées, définies par : 
A et B étant deux solides, 


(A U*B) = r(AUB) 
(AN*B) = r(ANnB) 
(A+B) = r(A-B) 


où r désigne l'application qui, à un sous-ensemble de E‘, associe 
l'adhérence de son intérieur. 
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a conception assistée par ordinateur a connu de nombreuses évolutions 

durant ces dernières années. Bien qu'elle ait atteint une certaine maturité, en 
particulier sur les aspects morphologiques (modélisation géométrique, voir 
[H 3 7501), la technologie va encore induire de profondes mutations dont nous 
montrons dans cet article l’état actuel des développements dans les systèmes, 
les tentatives de mise en œuvre d'une véritable modélisation fonctionnelle et 
quelques perspectives. 
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1. Évolutions de la CAO 


L'objectif de la CAO est de constituer une maquette virtuelle qui 
doit se comporter comme un prototype physique. Nous en sommes 
encore loin aujourd'hui. Il faut introduire dans l'ordinateur les pro- 
priétés de l'objet, parfois au prix de nombreuses opérations, et pou- 
voir ensuite les exploiter. Ainsi, la CAO permet de procéder à des 
simulations, ce qui a toujours été son objet principal. 


Il serait souhaitable que la CAO permette de concevoir un objet 
technique, mais ce n'est pas encore le cas. Devant son écran, l'opé- 
rateur de CAO doit commencer par la phase de dessin et non par 
l'aspect fonctionnel. La CAO, malgré ses trente années d'existence 
et ses indiscutables apports, n'en est qu'à ses balbutiements. 


1.1 Un développement en trois phases 


On peut distinguer trois phases essentielles dans le domaine 
d'utilisation de la CAO. 


B Années 1980 : le modèle géométrique 


Ce mode de CAO est toujours utilisé aujourd'hui dans la plupart 
des entreprises. En effet, la CAO est souvent décrite comme un bon 
outil de dessin, alors que la génération suivante de logiciels plus 
performants est déjà disponible. La CAO sert fondamentalement à 
résoudre des problèmes géométriques qui peuvent être relative- 
ment complexes. Ainsi, la prise en compte des surfaces par ces logi- 
ciels a été longue et délicate. Si limitée qu'elle soit, l'utilisation 
géométrique de la CAO a toutefois donné de bons résultats. 


Elle est caractérisée par le fait que les modèles de solides et de 
surfaces ont été développés selon des approches et des outils très 
différents (structures de données pour les solides, équations para- 
métriques pour les surfaces). 


Les modèles de surfaces sont tous basés sur l'utilisation de fonc- 
tions splines et de points de contrôle. Leurs différences sont essen- 
tiellement au niveau du contrôle de la forme (« plus global » en 
Bézier qu'en B-spline selon le degré) ou à la capacité de représenter 
des quadriques (cas des NURBS - non uniform rational B-splines - 
par exemple). 


Deux familles de modèles de solides cohabitent : 


— une représentation implicite (suite des opérations ayant permis 
la construction des objets) : le CSG (constructive solid geometry) ; 


— une représentation explicite (formes de l'objet) : le B-Rep (boun- 
dary representation ou modèle par les frontières). 


L'apparition dans les systèmes commerciaux du paramétrage 
(modèle implicite) à la fin des années 1980, permettant d'avoir des 
modèles plus dynamiques, a été un élément important de l'utilisa- 
tion de la CAO. 


Toutes ces notions sont détaillées dans l'article [H 3 750]. 


B À partir de 1995 : le modèle de produit 


À partir de 1995, les utilisateurs de CAO ne souhaitaient plus dis- 
poser d’un simple modèle géométrique, mais aussi d'un modèle de 
production. Le paramétrage a été introduit dans tous les systèmes : 
il permet de modifier facilement le produit fini par l'affectation de 
variables. Le système assure la cohérence du nouveau modèle. Les 
entités (features) sont des modèles sensiblement plus proches 
d'une logique de métier. Les objets considérés sont donc plus struc- 
turés. 


On dispose également d'informations qui permettent de créer des 
pièces définies par des équations. La définition mathématique des 
pièces n'est pas récente, mais il n’est désormais plus nécessaire de 
recourir à des programmeurs pour développer une application. 
L'utilisateur peut le faire seul devant son système relié à une base de 
données. Le système de CAO est capable de comprendre et d'inté- 
grer les demandes de l'utilisateur (figure 1). 


B Années 2000 : le modèle global 


La future conception assistée par ordinateur vise à modéliser non 
seulement le produit mais aussi le process associé. On en arrive 
ainsi à la prise en compte du produit, des procédés (de fabrication 
par exemple) et des processus. Aujourd'hui, on passe de la concep- 
tion à la fabrication d'un modèle, puis, une fois la nature du process 
déterminée, du modèle numérique à la production. Un tel schéma 
disparaîtra sous peu, car la simulation sera davantage intégrée au 
processus de production (figure 2). Il est clair que de nombreuses 
applications sont des réussites dans les entreprises, à travers la 
maquette numérique, l'intégration de la simulation ou la liaison 
CAO/SGDT (système de gestion des données techniques). 


La problématique reste la modélisation d'une réalité concrète par 
des modèles de plus en plus complexes et dynamiques. L'objectif 
fondamental consiste toujours à formaliser le concret pour disposer 
de modèles représentant les propriétés de la réalité aussi bien que 
possible et de pouvoir les exploiter au mieux. 
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Figure 1 - Exemples d’entités et d'utilisation de systèmes de CAO 
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(@) mannequin (doc. ESI) (B) formage (doc. ES) 


(©) visualisation (doc. Enovia) @ déformation (doc. Catia) 


Figure 2 - Exemples de simulations 


1.2 Orientation PROŸ 


L'orientation produit/procédé/processus est la base des dévelop- 
pements les plus prometteurs. Dans un environnement de travail 
collaboratif, ces trois aspects sont liés. 


Le produit est défini comme l'ensemble des informations repré- 
sentant (au sens du modèle déjà introduit) l'ensemble du produit. Le 
produit doit répondre à l'attente d'un client et doit satisfaire les con- 
traintes économiques et fonctionnelles demandées. 


Le procédé représente tout phénomène abstrait ou physique qui 
contribue à transformer un produit. Une opération booléenne est un 
procédé, tout comme une fabrication par frittage de poudre ou par 
usinage. Un procédé est caractérisé par ses performances (qualités 
intrinsèques) et les contraintes qu'il induit (qualités extrinsèques). 
Ces contraintes peuvent avoir une importance en aval du procédé 
(qualité de surfaces qu'il faudra améliorer, par exemple), mais égale- 
ment en amont (on ne conçoit pas obligatoirement un objet de la 
même façon selon qu'il sera fabriqué par tel ou tel procédé). La dis- 
tinction entre produit et procédé peut être fonction du point de vue : 
une presse à injecter est un produit ; sa mise en œuvre fournit un 
procédé pour la mise en forme de matériaux plastiques. 


Le processus est déterminé par un ensemble de phases dont la 
mise en œuvre procure un résultat transformant le produit. Il s’agit 
donc d’une notion qui se rapproche de la gamme de fabrication par 
exemple. Cependant, la notion de processus peut également 
s'appliquer à une activité abstraite (par exemple, lors des premières 
phases de conception). 


Nous nous attachons plus particulièrement dans la suite à la 
notion de modélisation du produit. En effet, si la prise en compte du 
triptyque produit/procédé/processus est un objectif indéniable, 
nous nous intéressons dans cet article, avant toute chose, au fait de 
disposer d'un modèle du produit possédant une sémantique plus 
élevée que celle de la morphologie, des méthodologies et des outils 
de dialogue facilitant sa définition (le produit doit répondre à un 
cahier des charges). Sans entrer dans les détails et les différentes 
approches des méthodes de conception, nous donnons quelques 
éléments nécessaires à la compréhension de l'intérêt des outils 
informatiques développés. 
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Figure 3 - Cycle élémentaire de conception 


1.3 Vers une véritable assistance 
au processus de conception 


Il n'entre pas dans les objectifs de cet article de décrire de manière 
approfondie le processus de conception. Cependant, il est indispen- 
sable de donner quelques éléments qui permettent de comprendre 
en quoi les systèmes de CAO actuels ne répondent que très partiel- 
lement aux démarches et aux contraintes de ce processus et de 
quelle manière on peut envisager des évolutions positives. Le pro- 
cessus de conception correspond à une démarche générale qui spé- 
cifie un ensemble d'étapes distinctes ayant chacune un but 
différent. En effet, les premières de ces phases (ou étapes) permet- 
tent au concepteur de prendre des décisions concernant les fonc- 
tions du produit à concevoir, les caractéristiques désirées et 
indésirables, alors que les dernières phases ont pour but de réaliser 
les spécifications pour assurer une fabrication efficace. Il est com- 
munément admis que le processus de conception passe par une 
décomposition de fonctions initiales (cahier des charges) en sous- 
fonctions appropriées qui sont réalisées par des composants. Ces 
composants sont ensuite assemblés pour constituer le résultat du 
processus en un produit répondant aux fonctions et à des contrain- 
tes économiques et de fabrication en particulier. 


Bien que chaque entreprise puisse définir son propre processus, 
aborder le processus de conception en cinq étapes, même si le pro- 
cessus est de moins en moins linéaire, représente assez bien 
l'ensemble des approches. La conception fonctionnelle consiste à 
décrire de manière structurée les différentes fonctions. La concep- 
tion conceptuelle permet d'élaborer une structure réalisant les fonc- 
tions décrites dans l'étape précédente, tout en évitant celles qui sont 
indésirables. Des idées et des concepts sont générés et évalués à un 
niveau abstrait. La conception intégrée permet de définir le lien 
entre les fonctions du produit et les entités physiques. La concep- 
tion détaillée permet de raffiner la conception des différents sous- 
modules identifiés dans l'étape de conception intégrée. Le niveau 
de raffinement doit être suffisant pour la fabrication. Enfin, l'analyse 
d'ingénierie consiste à vérifier que les spécifications données dans 
les étapes de conception fonctionnelle et conceptuelle sont bien réa- 
lisées dans la version finale du produit. 


Le cycle élémentaire de conception consiste en quelques étapes 
clés (figure 3) [1][21. 


La première phase d'analyse aboutit à des critères (qui peuvent 
suffire dans des conceptions simples) et une phase de synthèse per- 
met une proposition de conception. Cette proposition est simulée 
(simulation numérique, prototypes, etc.) pour vérifier que les pro- 
priétés attendues sont respectées. Dans ce cas, la proposition est 
évaluée pour permettre une prise de décision (approbation ou non 
de la proposition). Bien entendu, de nombreux retours en arrière (ou 
une exécution simple, voire l'inutilité de certaines phases) intervien- 
nent. Il s'agit généralement d’un problème de satisfaction de con- 
traintes, difficile dans le cas de problèmes complexes. On note 
également que ce processus n'est pas linéaire (comme pourrait le 
faire croire la figure 3), c'est-à-dire que les phases peuvent se dérou- 
ler en parallèle et qu'il est itératif, c'est-à-dire qu'une solution sert 
souvent de cahier des charges à un approfondissement de la 
conception. 


Un exemple simple suffit à comprendre combien on est loin 
aujourd'hui de véritables systèmes d'assistance à la conception. 
Dans [3], on considère la conception d'un vélo tout terrain (VTT). Ce 
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VTT doit pouvoir évoluer sur tous les terrains, être de type polyva- 
lent ou descente et susceptible d’être classé en trois catégories (loi- 
sirs, sportif ou compétition). || ne doit transporter qu'une seule 
personne (pas de tandem par exemple), être vendu dans une cer- 
taine gamme de prix, être apprécié par les jeunes de 15 à 25 ans et, 
enfin, sa maintenance doit être facile. 


On constate que plusieurs types de fonctions cohabitent. La 
notion de beauté ne s'exprime pas de la même façon que celle du 
prix du produit dans la mesure où la première est plutôt subjective 
alors que la deuxième est objective. Les fonctions objectives sont, 
en général, plus facilement représentables. On perçoit donc l'exis- 
tence d'une typologie des différentes fonctions pouvant intervenir 
dans la description d'un produit industriel : 


— du texte pouvant exprimer la fonction beauté ; 

— des équations mathématiques pouvant, entre autres, exiger 
que l’âge des utilisateurs soit compris entre 15 et 25 ans, de la logi- 
que floue, etc. ; 

— des schémas (pour représenter une forme ergonomique de 
guidon, par exemple) ; 

— des formes tridimensionnelles correspondant aux parties dont 
la géométrie est plus ou moins bien définie. 


Les fonctions que nous avons définies dans les spécifications ini- 
tiales sont de haut niveau, difficilement interprétables par un sys- 
tème informatique. Généralement, on décompose les différentes 
fonctions en sous-fonctions, elles-mêmes décomposées en d’autres 
sous-fonctions, ce qui permet d'arriver à un niveau compréhensible 
par un système. 


Considérons le fait que le VTT est un vélo. Le concepteur peut se 
trouver face à deux situations : soit la notion de vélo existe sous une 
forme ou sous une autre et peut donc être utilisée pour préciser le 
VTT, soit le système n'a pas réussi à reconnaître une telle fonction. 
Dans ce cas, il doit la mettre en œuvre à l’aide du concepteur. Sup- 
posons que nous soyons obligés de décrire, à l'aide du système 
informatique, la fonction vélo (figure 4). 


Un vélo est un dispositif qui permet de se propulser, de se guider, 
de s'asseoir, de freiner, de subir des chocs d'une certaine puissance 
sans se déformer. Nous admettons qu'à ce niveau, le système n'est 
pas susceptible de reconnaître l'ensemble de ces fonctions. Consi- 
dérons, par exemple, la fonction propulsion. Un système de péda- 
lier ou de rameur peut, par exemple, réaliser cette fonction, ce qui 
conduit à plusieurs solutions. Le système devra donc envisager 
d'enregistrer les différentes possibilités proposées par le concep- 
teur pour permettre une résolution plus large. Il semble évident, en 
effet, que le choix d'un système de propulsion peut influencer forte- 
ment le mécanisme de freinage, ou encore les « design » du produit 
final, par exemple. 


Figure 4 - Hiérarchie de la fonction VTT 
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Il existe, pendant la décomposition fonctionnelle, une obligation 
de réaliser un certain nombre de fonctions (guidage, propulsion, 
etc.) et des choix ou des alternatives (pédalier, rameur, etc.). || appa- 
raît de manière évidente que la décomposition fonctionnelle corres- 
pond à une certaine hiérarchie dans la mesure où une fonction (le 
vélo, par exemple) peut faire référence à une autre fonction. Il serait 
très utile pour le concepteur que le système puisse détecter automa- 
tiquement des fonctions ayant été déjà réalisées soit dans un autre 
produit, soit dans le produit en cours de réalisation. De cette 
manière, il suffirait à l'utilisateur de simplement préciser la fonction 
au système pour que celui-ci propose une décomposition associée. 
Modéliser les différentes alternatives permet de retracer l'ensemble 
des possibilités de conception pour une conception donnée afin que 
le système informatique signale que telle solution est réalisable 
parce que tel autre choix a déjà été fait ou, justement, est infaisable 
parce que telles autres alternatives ont été choisies. Cette fonctiona- 
lité du système n'est envisageable qu'à l'aide de mécanismes d'aide 
à la décision. En fin de processus, on associera des formes aux fonc- 
tions. 


Il'est indéniable que, sauf dans des travaux de recherche, ces dif- 
férents aspects ne sont pas bien pris en compte actuellement. En 
général, le concepteur utilise la CAO pour la conception des formes 
et de leur assemblage et peu d'outils lui permettent de s'assurer de 
la cohérence et du respect des fonctions, encore moins d'aborder 
les problèmes par les fonctions. 


Notre objectif est de présenter ce qui, dans les évolutions de la 
CAO, peut donner des solutions à la prise en compte des fonctions 
ou, au moins, des pistes prometteuses. Nous abordons dans le 
paragraphe 2 la modélisation par les entités (ou features) que l'on 
peut considérer comme assez bien prise en compte dans la plupart 
des systèmes. Il s'agit d'une première approche par un enrichisse- 
ment de la géométrie. Nous abordons ensuite les travaux actuels 
sur la prise en compte des fonctions qui reste encore embryonnaire 
dans les systèmes du marché. Enfin dans la mesure où l'ensemble 
des aspects liés à la conception et à la fabrication d'un produit n'est 
pas intégré dans un modèle unique, nous donnons les éléments 
nécessaires à la compréhension des échanges et des partages de 
données entre systèmes. 


2. Modèles basés 
sur les entités 


Les modèles mis en œuvre dans les systèmes de CFAO actuels 
sont essentiellement de type géométrique. Or, un modèle géométri- 
que comporte un certain nombre de limites, maintenant bien 
connues, dont les deux plus importantes sont : 


— les informations sont incomplètes (uniquement géométriques) ; 
— les dimensions sont en nominal, ce qui interdit toute liaison 
avec les contraintes de fabrication. 


D'où la volonté de gérer des informations sur la forme (géomé- 
trie), des informations technologiques, des informations de toléran- 
cement (macro- et microgéométriques), des informations sur les 
matériaux (propriétés physiques ou mécaniques), des informations 
spécifiques à une application donnée (éléments finis, commande 
numérique, etc.), des informations administratives (références vers 
un fournisseur, etc.). 


On s'efforce donc, de plus en plus, d'enrichir les modèles actuels 
pour définir de véritables modèles de produit. Parmi les besoins que 
devrait satisfaire un modèle de produit, on peut citer : 

— utiliser un « langage métier » : le dialogue doit s'appuyer sur 
des notions « métier » et référencer des entités les intégrant ; 

— vérifier que les tolérances permettent l'assemblage ; 

— engendrer la gamme de fabrication ; 

— contrôler la qualité par comparaison avec le modèle. 
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2.1 Notion d'entité 
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Un modèle de produit s'appuie essentiellement sur des enti- 
tés et des caractéristiques. Définissons les termes « entités » et 
« caractéristiques ». 

Une entité est un objet comprenant « toutes » les informa- 
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du modèle lui-même, mais également du dialogue qui pourra lui 3 c 
être associé : le dialogue, au sens de langage métier, influe directe- 
ment sur les spécificités du modèle. L'approche « produit » (features 
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— des informations de précision, qui explicitent les tolérances de - 
fabrication par rapport à la forme idéale ; 

— des informations matérielles, qui donnent le type de matériau 
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et donc ses propriétés ; Vis à métaux CZX - tête cylindrique basse à 6 lobes 1. NF E 25-111 
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Vis à métaux CS - tête cylindrique fendue - Grade À NF E 25-127 


— des informations administratives, qui facilitent la gestion de Vis à métaux CL S - tête cylindrique large fendue - Gr. NF E 25:128 


l'objet (référence, fournisseurs, existence en stock, etc.). 


On ne peut pas considérer cette approche, très à la mode actuel- 
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ormalisation et standardisation se révèlent être, dans les technologies de 

l'information et de la communication (TIC), de puissants facteurs de dif- 
fusion. Par exemple, jusqu'en 1989, le marché du CD-Rom a stagné. Comme il 
n'y avait pas d'accord entre les différents industriels sur le formatage des don- 
nées stockées, les éditeurs étaient peu enclins à adopter le CD-Rom comme 
support de leurs publications, en raison du risque de dépendance technologi- 
que. Lorsque les constructeurs se sont accordés sur une norme internationale, 
ce risque de dépendance a disparu, les CD-Rom devenant lisibles sur une 
gamme plus large de matériels. Ce n'est qu'à ce moment-là que le marché de 
l'édition électronique s'est vraiment ouvert. 


Dans cet article, on se propose de faire un large tour d'horizon de ce que l’on 
regroupe sous les vocables de normalisation et de standardisation. Après avoir 
bien distingué ces deux approches souvent concurrentes, même si elles sont 
parfois complémentaires, il s'agira de présenter quelques-uns des organismes 
de normalisation les plus importants, qu'ils soient internationaux (ISO, UIT, 
IETF), à l'échelle d’un continent (ECMA, ETS) ou nationaux (Afnor, ANSI, DIN). 
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Ce sera également l’occasion de présenter les méthodes de travail utilisées dans 
ces organismes pour produire les documents de référence : on verra ainsi que 
les délais de production d’une norme ou d’un standard, souvent considérés 
comme longs, sont justifiés par le soin mis à la recherche du plus grand 
consensus possible entre des acteurs aux intérêts souvent divergents. La pré- 
sentation des grandes normes du multimédia (JPEG, MPEG) et quelques indi- 
cations sur d’autres normes importantes du domaine des TIC (codage de 
caractères, architecture de documents) serviront à illustrer l'apport de ces orga- 
nismes et de ces méthodes. On reviendra en conclusion à la problématique 
norme « vs » standard en évoquant quelques lieux de standardisation impor- 
tants et en indiquant comment un standard peut, le cas échéant, devenir une 


norme. 


1. Organismes 
de normalisation 


MB Là où l'anglais n'utilise qu'un terme, standard, le français en uti- 
lise deux : norme et standard. 


On a coutume, en effet, d'opposer les normes, documents 
validés par des instances officielles et qui, de ce fait même, 
offrent une certaine garantie de stabilité et de pérennité, aux 
standards, états de fait résultant de mécanismes économiques 
et traduisant souvent la domination d’un industriel ou d'un 
groupe d'industriels sur un marché. 


On pense souvent, à tort, que la distinction entre norme et stan- 
dard tiendrait à ce que celui-ci est utilisé de façon volontaire alors 
que celle-là est d'application obligatoire. Les choses ne sont pas si 
simples. Une norme internationale, par exemple, n'a force légale 
que si une instance nationale, l'Afnor pour la France, la reprend. En 
revanche, une norme européenne est bien d'application obligatoire 
dans tous pays de l'Union européenne, même dans le pays qui ne 
l'a pas votée. Réciproquement, il est des domaines dans lesquels 
il est fort difficile d'échapper à un standard, les utilisateurs qui 
désirent acheter un ordinateur personnel (PC) sans système 
d'exploitation ou avec un autre système que le système standard 
en savent quelque chose. 


En nous appuyant sur cette distinction entre norme et standard, 
nous allons d'abord présenter les organismes de normalisation 
puis évoquer quelques-unes des normes les plus connues dans le 
domaine des technologies de l'information et de la communication 
(TIC). Nous pourrons alors revenir à une présentation des organis- 
mes de standardisation et conclure en évoquant les moyens qu'ont 
les standards de devenir des normes. 


B Pour qui n’est pas familier du monde de la normalisation, il est 
souvent stupéfiant de découvrir à quel point ce monde est éclaté 
en des dizaines d'entités parfois concurrentes. 


On pourrait imaginer, en effet, compte tenu du sujet, un orga- 
nisme unique chargé de normaliser toutes les activités indus- 
trielles. Ce serait oublier que la normalisation doit prendre en 
compte des intérêts souvent contradictoires : ceux des industriels, 
ceux des États, ceux des consommateurs. C'est ce qui explique 
que le processus de normalisation se trouve éclaté dans de multi- 
ples organismes reflétant les différentes approches que l'on peut 
avoir d'un même sujet. 


e La première segmentation que l'on peut faire tient à l'espace 
géographique. À l'heure de la mondialisation, on sait bien qu'il sub- 
siste trois grands niveaux de prises de décision : 
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— un niveau mondial ; 
— un niveau dit régional (Europe, Amérique du Nord, Asie) ; 
— un niveau local, celui des Etats. 


Nous verrons donc des organismes de normalisation représen- 
tatifs de ces trois niveaux. 


e La deuxième segmentation tient aux domaines traités. Pour 
ce qui concerne les technologies de l'information et de la 
communication, cette segmentation conduit là encore à trois sous- 
domaines : 


— l'informatique au sens large ; 
— les télécommunications ; 
— l'Internet. 


La normalisation de ces trois sous-domaines est, en effet, effec- 
tuée par des organismes différents. Naturellement, tous ces orga- 
nismes cherchent plus ou moins à coordonner leurs travaux pour 
éviter redondances ou, ce qui serait encore pire, contradictions 
entre des normes. De façon limitée cependant, il arrive que 
quelques sujets soient traités par les uns et par les autres ou, 
ce qui est meilleur, par des groupes mixtes faisant appel aux res- 
sources de plusieurs entités. 


Dans ce qui suit, nous présentons tout d'abord la filière dans 
laquelle s'effectue la normalisation des activités de l'industrie de 
l'informatique : c'est l'ISO (Organisation internationale de normali- 
sation, 8 1.1) au niveau mondial et l’Afnor (Association française de 
normalisation, 8 1.2) en France. Ce sera l’occasion de présenter les 
méthodes et les processus d'élaboration d'une norme, méthodes 
fondées sur le consensus, et processus (rédaction de textes soumis 
à votes) que l'on retrouve dans pratiquement tous les organismes 
de normalisation. 


Dans un deuxième temps, nous présenterons la normalisation 
du domaine des télécommunications avec l'UIT (Union internatio- 
nale des télécommunications, 8 1.3) au niveau mondial et l'ETSI 
(Institut européen des normes de télécommunications, 8 1.4) au 
niveau européen. 


La normalisation (ou la standardisation) de l'Internet sera 
ensuite analysée au travers des activités de l'ISOC (Internet 
society, 8 1.5). 


Pour conclure cette partie, nous citerons un certain nombre 
d'organismes que l'on peut trouver dans la normalisation des TIC, 
en précisant leur rôle. 


1.1 Organisation internationale 
de normalisation (ISO) 
Nota : pour plus de détails sur cette organisation, le lecteur pourra consulter l'article 


Organisation internationale de normalisation (ISO) [R 83] dans le traité Mesures et 
contrôle des Techniques de l'Ingénieur. 
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Organisation non gouvernementale créée en 1947 et située à 
Genève, l'ISO (Organisation internationale de normalisation) est un 
réseau d'instituts nationaux de normalisation comportant plus de 
140 pays. Elle a vocation à élaborer des normes pour l'ensemble 
des activités industrielles sauf celles du secteur électrotechnique 
(c'est le rôle de la CEI, Commission électrotechnique internatio- 
nale) et celles du secteur des télécommunications (c'est le rôle de 
l'UIT, l'Union internationale des télécommunications, cf. 8 1.3) 

Nota : au passage, il faut noter que « ISO » n'est pas un sigle. C'est un nom qui a été 


choisi en pensant au grec isos qui signifie « égal », probablement parce que tous les indus- 
triels et les consommateurs sont égaux face à une norme. 


L'IS0 a trois langues officielles : 
— l'anglais ; 

— le français ; 

— le russe. 


En angjlais, on l'appelle International Organization for Standardi- 
zation et non /nternational Standards Organization comme on le 
voit trop souvent écrit ! Il faut cependant noter que l'anglais est, 
dans la pratique, la langue de travail usuelle. 


La participation à l'ISO est ouverte aux instituts nationaux de 
normalisation ou à des organisations analogues, représentatives 
de la normalisation dans leur pays. Les membres de l'ISO sont 
répartis en trois catégories : 


— les comités membres : organismes nationaux (un seul par 
pays) les plus représentatifs de la normalisation dans leur pays. Ce 
sont le DIN (Deutsches Institut für Normung, Allemagne), l'ANSI 
(American National Standard Institute, États-Unis), l'Afnor (France), 
le BSI (British Standard Institute, Royaume-Uni), etc. ; 

— les membres correspondants : en général, ce sont des orga- 
nisations dans des pays qui n'ont pas complètement développé leur 
activité nationale en matière de normalisation. Les membres cor- 
respondants ne prennent pas une part active aux travaux mais 
en sont tenus pleinement informés. C'est le cas, par exemple, de 
l'Albanie, du Cameroun ou du Soudan ; 

— les membres abonnés : en général, des pays en voie de déve- 
loppement qui n'ont pas les moyens d’avoir une politique active de 
normalisation mais qui souhaitent néanmoins être tenus informés 
des résultats acquis et être en contact avec la normalisation inter- 
nationale. C'est notamment le cas du Bénin, du Honduras ou de la 
Palestine. 


Les travaux techniques de l'ISO sont complètement décentra- 
lisés : pratiquement rien de technique ne se fait à Genève. Ces tra- 
vaux sont menés au sein de près de 3 000 comités techniques (TC), 
sous-comités (SC) et groupes de travail (WG) qui comptent au total 
plus de 30 000 experts. Ces experts ne sont pas des « fonction- 
naires de la normalisation » employés à plein temps par l'ISO 
mais, bien au contraire, proviennent des milieux industriels, des 


l'ISO. Les opérations sont gérées par un Secrétaire général dont la 
fonction est permanente. Le Secrétaire général fait rapport à un 
Président, personnalité éminente dans le domaine de la normalisa- 
tion ou de l'économie, élu pour deux ans. Le Secrétaire général est 
basé au Secrétariat central de l'ISO à Genève. Doté d’un personnel 
restreint, il a pour rôle d'assurer la bonne circulation des docu- 
ments mais aussi de clarifier les points de procédure ou les pro- 
blèmes administratifs que lui soumettent les secrétaires et les 
présidents de comités techniques. Il est également responsable 
des soumissions aux votes des comités membres des projets de 
normes. En outre, il coordonne le programme décentralisé d’élabo- 
ration des normes définitives et procède à leur publication. 


1.1.1 Élaboration d’une norme internationale 
à l'ISO 


B Trois principes guident l'élaboration d'une norme internationale 
à l'ISO. 

Le consensus tout d'abord. Nous l'avons déjà évoqué, il s’agit, 
au cours de l'élaboration de la norme, de savoir prendre en compte 
le point de vue de tous les acteurs : fabricants, vendeurs et utili- 
sateurs, groupes de consommateurs, laboratoires d'essais, gou- 
vernements, professionnels de l'ingénierie et organismes de 
recherche. 


Mais il s'agit aussi de mettre en place une norme qui soit appli- 
cable à l'échelle industrielle, en particulier qui soit compatible ou 
cohérente avec l'existant et qui vise à satisfaire les industries et les 
clients partout dans le monde. 


Il s'agit enfin d'une démarche volontaire : mue essentiellement 
par le marché, la normalisation s'appuie sur la participation volon- 
taire de tous les acteurs intéressés. 


B Trois grandes phases caractérisent le processus d'élaboration 
d’une norme internationale. 


e La première phase part de l'expression du besoin et va jusqu'à 
la définition de l'objet technique de la future norme. Lorsque tel ou 
tel acteur ressent le besoin d’une norme internationale, il en fait part 
à son comité membre national. Celui-ci soumet le projet à l'ISO et, 
sitôt que ce besoin a été reconnu et formellement approuvé, des 
groupes de travail constitués d'experts provenant des pays intéres- 
sés se mettent à la définition de l’objet technique de la future norme. 


e Lorsqu'un accord se fait sur cette définition, une deuxième 
phase commence au cours de laquelle les différents experts mettent 
au point les détails des spécifications de la norme. Cette phase, très 
importante, se fait toujours en recherchant le plus large consensus. 


e La troisième et dernière phase est celle de l'approbation for- 
melle du proiet de norme internationale : là encore. le plus larae 
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ans le domaine du traitement de l'information, du logiciel et plus généra- 
lement pour tout ce qui concerne les systèmes informatiques, la 
recherche de la qualité est la préoccupation de tous les acteurs. Toutefois, le 
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manque de temps, la valse des évolutions technologiques et les contraintes de 
tous ordres semblent reléguer les aspirations de qualité au rang des objectifs 
inaccessibles et des mythes. 


Pourtant, la qualité se résume simplement à la satisfaction des clients et par 
extension à l'atteinte de la satisfaction des exigences de tous les partenaires qui 
interviennent dans une opération ou un projet (utilisateurs, décideurs, organisa- 
teurs, acheteurs, chef de projet, concepteurs, développeurs, testeurs, exploitants, 
etc.). 


Bien qu'immatériel, le logiciel n'échappe pas à ce principe fondamental. Afin 
de contribuer à l'amélioration de la qualité dans le domaine du logiciel, les 
experts internationaux de l'ISO se sont mis d'accord sur une base commune 
qui constitue une plate-forme normative. 


Ces référentiels normatifs matérialisent notre point d'appui pour construire la 
qualité des processus d'ingénierie de projet ou d'exploitation. La qualité de 
livrables (produits logiciels et prestations qui les accompagnent) fait l’objet des 
dossiers [H 4 029]. Les bonnes pratiques de maîtrise du cycle de vie du logiciel 


font l'objet du dossier [H 4 031]. 


1. La qualité, une exigence 
pour les technologies 
de l'information 


L'informatique est le domaine d'activité qui concerne le traitement 
de l'information par des équipements électroniques (ordinateurs). 
Ces traitements de l'information reposent sur deux éléments : 


—le matériel (hardware), composants électroniques, cartes et 
périphériques ; 

—le logiciel (software), ensemble d'instructions système ou 
applicatives pour l'acquisition, le stockage, la transformation, la 
transmission et la restitution automatique de données. 


Le logiciel est un produit industriel un peu particulier. Il se 
matérialise par des instructions de code sous la forme de don- 
nées implantées sur un support physique. 


Comme tout produit industriel, il doit répondre à des besoins for- 
mulés par des clients/utilisateurs qui expriment des exigences. Le 
concept d'un produit prend naissance dans l'esprit des ingénieurs 
qui imaginent puis dessinent ses fonctionnalités. Ensuite, des déve- 
loppeurs le font passer de l'état de plan ou de maquette à l'état de 
produit manufacturé. C'est la notion de cycle de vie (processus). 
L'originalité du logiciel réside dans le fait qu'il s’agit d'un produit 
immatériel. On peut dire que c'est un produit du monde virtuel 
parce qu'invisible. Par contre, ses effets sont quant à eux bien réels. 


Toutefois, dans le cadre des échanges fournisseurs - clients - 
utilisateurs, le logiciel est rarement livré tout seul. Il est 
accompagné de documentation, de formation, d'assistance, de 
maintenance voire d'exploitation, qui comportent des caractéris- 
tiques propres à la notion de service. L'assemblage des attributs 
produits et des attributs service conduit à utiliser de préférence le 
terme de prestations de services. 


La diversité des technologies de l'information, le grand nombre 
de textes normatifs qui s'y rattachent et la richesse des retours 
d'expérience, nous ont conduits à aborder ce thème de la qualité 
d'une manière segmentée. Ainsi, nous proposons une approche en 
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trois parties. Chaque partie est couverte par un dossier qui consti- 
tue un angle de vision différent mais complémentaire. Le présent 
dossier développe la vision processus d'ingénierie. 


2. Référentiels normatifs 
applicables 


Le logiciel, bien que produit relativement récent n'échappe pas 
au champ d'investigation des instances normatives internationales 
(ISO et AFNOR). 


Les normes ISO 9000 relatives au management de la qualité sont 
applicables à tout organisme, donc aussi aux organismes qui 
conçoivent, fabriquent et vendent du logiciel, notamment en ce qui 
concerne leur certification. 


Mais les instances internationales ont aussi rédigé des normes 


spécifiques, adaptées pour le logiciel. Nous allons en résumer les 
principales. 


2.1 Cartographie normative 


Parmi les très nombreuses normes relatives au logiciel, les prin- 
cipales peuvent être classées selon deux grandes catégories fon- 
damentales (figure 1) : 

— la catégorie des normes applicables aux processus d'ingénierie ; 

— la catégorie des normes applicables aux produits logiciels. 


PROCESSUS 


ISO/CEI 12207 ISO/CEI 155041 
(Modèle) (Évaluation) 


Nouvelle 
numérotation 
ISO/CEI 33000 


ISO 9000 
(qualité) 


PRODUITS 


ISO/CEI 9126 ISO/CEI 14598 
(Modèle) (Évaluation) 


Nouvelle 
numérotation 
ISO/CEI 25000 


Figure 1 - Cartographie normative pour le logiciel 
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En complément de ces normes fondamentales, citons l'appa- 
rition des nouvelles séries 33000 pour les processus et 25000 pour 
les produits logiciels. 


Il'existe aussi deux autres séries de normes intéressantes : 

— la série ISO/CEI 20000 qui concerne la qualité des prestations 
de services Information Technology ; 

— la série ISO/CEI 27000 qui concerne la sécurité de l'information. 


2.2 Organisation de nos dossiers 


Pour tenir compte de la segmentation de ces approches norma- 
tives pratiquées par les experts internationaux, la présentation des 
dossiers est la suivante : 


— un lot de trois dossiers orientés vers les études et réalisations 
informatiques : 


e Processus d'ingénierie informatique [H 4 028v2], 
e Produit logiciel [H 4 029], 
e Gestion du cycle de vie du logiciel [H 4 031]; 


— un dossier [H 3 280] qui traite de la maîtrise des prestations de 
service Information Technology (ISO/CEI 20000). Ce dossier est 
orienté vers la production des services informatiques et est intitulé 
ITIL et ISO 20000 ; 


- un dossier [H 5 070] (à paraître) qui traite de la maîtrise de la 
sécurité de l'information (ISO/CEI 27001). 


3. Instances 


3.1 ISO 


ISO (International Organization for Standardization) est une fédé- 
ration internationale des organismes nationaux de normalisation. 


Le travail de préparation des standards internationaux est nor- 
malement mené par les comités techniques ISO. Chaque orga- 
nisme national intéressé par un sujet pour lequel un comité 
technique a été établi a le droit d'être représenté à ce comité. 


3.2 CEI 


La Commission électronique internationale (IEC) s'occupe de 
tous les sujets qui concernent les standards électrotechniques et 
informatiques. 


3.3 AFNOR 


L'Association française de normalisation (AFNOR) est le repré- 
sentant de l'ISO en France. Elle a pour mission d'animer, de coor- 
donner l'élaboration des normes et de promouvoir leur utilisation. 


3.4 Normes 


Les normes internationales (standard) sont réalisées et adoptées 
par les comités techniques, puis elles sont distribuées aux 
membres pour le vote. La publication en tant que standard interna- 
tional nécessite l'approbation d'au moins 75 % des membres parti- 
cipant au vote. 


4. Norme ISO 9000 


4.1 Contexte 


La norme ISO 9000 est une norme internationale qui définit les 
exigences standard à respecter afin de mettre en place un système 
de management de la qualité (SMQ). Cette norme est générique, 
c'est-à-dire qu'elle n’a pas été rédigée spécialement pour les activi- 
tés relatives aux technologies de l'information. Elle est applicable à 
tout organisme quel que soit son domaine d'activité. 


De plus en plus, ce référentiel qualité est combiné avec un ou 
plusieurs autres référentiels spécialisés afin de constituer des sys- 
tèmes de management intégrés (SMI). C'est notamment le cas 
avec l'environnement (ISO 14001), la santé et la sécurité au travail 
(OHSAS 18001), les prestations de services des technologies de 
l'information (ISO/CEI 20000) ou la sécurité de l'information 
(ISO/CEI 27001). 


4.2 Structure normative 


En fait, il n'y a pas une seule norme ISO 9000 pour la qualité 
mais un ensemble de plusieurs normes qui se complètent. 


Cet ensemble comprend trois normes relatives à la qualité : 


— l'ISO 9000 (version 2005) qui décrit les principes essentiels et 
qui définit le vocabulaire à utiliser ; 

— l'ISO 9001 (version 2008) qui spécifie les exigences pour élabo- 
rer, construire, mettre en place et maintenir un système de mana- 
gement de la qualité. Cette norme constitue le référentiel qui 
permet d'obtenir une certification. Le certificat étant délivré par un 
organisme de certification accrédité, en France par le COFRAC, 
après un audit effectué par un auditeur certifié qui doit vérifier que 
toutes les exigences sont satisfaites ; 

— l'ISO 9004 (version 2009) qui fournit des lignes directrices 
(mode d'emploi ou bonnes pratiques non normatives mais utiles) 
pour l'amélioration des performances du système de management 
de la qualité. 


Et une norme d'audit : 


— |1SO 19011 (version 2002) qui définit les exigences pour l'audit 
des systèmes de management de la qualité (SMO) et des systèmes 
de management environnementaux (SME). 


Pour plus de détails, notamment sur les aspects de certifi- 
cation, se reporter aux nombreuses publications de l’auteur 
citées dans la bibliographie [5] [7] [8] [11] [12] [13] [14]. 


4.3 Contenu de l'ISO 9001 


Comme toutes les normes internationales, la norme ISO 9001 
est structurée par articles : 


- l'article 1 indique le périmètre concerné par la norme, son 
champ d'application ; 

-— l'article 2 précise les références des normes auxquelles on peut 
se reporter ; 

- l'article 3 donne les définitions des termes nouveaux ou ceux 
qu'il est utile de préciser afin de lever toutes les ambiguïtés 
sémantiques. 


Les exigences relatives à la définition, à la construction, à la 


mise en œuvre et à l'entretien d'un système de management de la 
qualité (SMO) sont définies dans les articles suivants : 


- l'article 4 décrit les exigences générales et les exigences rela- 
tives à la documentation ; 
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-— l'article 5 décrit les exigences applicables à la responsabilité de 
la direction (politique, planification, responsabilité et autorité, 
communication et revue) ; 

- l'article 6 décrit les exigences relatives au management des 
ressources (ressources humaines, infrastructures et environ- 
nement de travail) ; 

- l'article 7 décrit les exigences relatives à la réalisation du pro- 
duit ou du service délivré par l'organisme à ses clients. Véritable 
cœur de métier pour lequel le système de management assure la 
qualité délivrée aux clients. Cet article couvre la planification, les 
processus avec les clients, la conception et le développement, les 
achats, la production proprement dite et la maîtrise des équi- 
pements (y compris les logiciels) de surveillance et de mesure ; 

enfin l'article 8 décrit les exigences applicables à la sur- 
veillance du bon fonctionnement du système de management et à 
son amélioration. La maîtrise du système de management 
comporte un processus en prévision du traitement des produits ou 
services défectueux (non conformes aux exigences prévues avec 
les clients). 


4.4 Apports d'un système 
de management 


Un organisme qui se dote d’un système de management va 
bénéficier d'un certain nombre d'avantages concurrentiels par rap- 
port à un organisme qui en est privé. 

À savoir : 

1) une orientation très marquée pour satisfaire le client ; 

2) l'engagement très fort de la direction (politique, objectifs) ; 

3) des processus et des procédures de gestion clairement 
formalisés ; 

4) une organisation de surveillance et de mesure du système de 
management ; 

5) une maîtrise des dysfonctionnements ; 

6) une volonté de s'améliorer en permanence. 


Tous ces apports sont très importants pour garantir que les 
livrables logiciels et les prestations de service qui leur sont asso- 
ciées correspondent aux besoins exprimés par les clients/utilisa- 
teurs et leur donne entière satisfaction. 


5. Norme ISO/CEI 12207 


5.1 Contexte 


- des noms et des structures communes pour les processus 
applicables à la fois au système (ISO/CEI 15288) et au logiciel 
(ISO/CEI 12207) ; 

— les retours d'expériences de plus de 10 années d'utilisation des 
deux normes relatives aux cycles de vie des systèmes et du logiciel. 


Cette norme internationale peut être utilisée de différente manière : 


— soit par une organisation afin d'établir un environnement per- 
sonnalisé de processus ; 

— soit par un projet afin de cadrer les processus du cycle de vie 
de réalisation de produits logiciels ou de services logiciels ; 

— soit entre un acheteur et un fournisseur pour définir les activi- 
tés et les processus de la relation ; 

— soit par des évaluateurs afin de réaliser des évaluations 
contribuant à un processus d'amélioration. 


5.2 Structure normative 


Comme toutes les normes ISO, cette norme comporte trois 
premiers paragraphes relatifs aux généralités et aux références 
normatives. 


Ensuite, dans le paragraphe 4 sont données des définitions pré- 
cises de vocabulaire qui permettent de lever toute ambiguïté sur 
les termes utilisés. 


Le paragraphe 5 est consacré aux règles d'application de cette 
norme. Notamment à la présentation des concepts utilisés. Sont 
aussi décrites les relations qui existent entre «système» et 
« logiciel » ; entre « produit » et « prestation de service ». Ce para- 
graphe détaille aussi les différentes catégories de processus qui 
couvrent le cycle de vie. Puis, le canevas de description de proces- 
sus est exposé. 


Le paragraphe 6 présente tous les processus de cycle de vie 
relatifs à un système. 


Le paragraphe 7 présente tous les processus de cycle de vie 
relatifs à un logiciel. 


L'annexe A est importante car elle est classée normative. Elle 
concerne le processus d'adaptation des exigences de la norme afin 
de prendre en compte des circonstances particulières. Elle décrit le 
processus, son but, ses résultats et ses activités. 


L'annexe B est importante car elle est aussi classée normative. 
Elle concerne le modèle de référence des processus (PRM). Elle 
assure la mise en conformité avec l'ISO/CEI 15504 partie 2 pour 
permettre l'évaluation de la qualité des processus. 


Les autres annexes sont informatives. Nous signalons toutefois 
l'annexe D qui met en perspective les processus de l'ISO/CEI 12207 
avec les processus de l'SO/CEI 15288 (cf. 8 8). 


La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 


Si vous souhaitez accéder au contenu intégral de cette base documentaire, rendez-vous 


à la fin de ce document. 
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6. Conclusion = 11 


D ans le domaine du logiciel, et plus généralement, pour tout ce qui 
concerne les systèmes d'information, la recherche de la qualité est la pré- 
occupation de tous les acteurs. Toutefois, le manque de temps, la valse des 
évolutions technologiques, et les contraintes de tous ordres, semblent reléguer 
les aspirations de qualité au rang des objectifs inaccessibles et des mythes. 


Pourtant, la qualité se résume simplement à la satisfaction des clients, et par 
extension, à l'atteinte de la satisfaction des exigences de tous les partenaires 
qui interviennent dans une opération ou un projet (utilisateurs, décideurs, 
organisateurs, acheteurs, chef de projet, concepteurs, développeurs, testeurs, 
exploitants, etc.). 
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Bien qu'immatériel, le logiciel n'échappe pas à ce principe fondamental. Afin 
de contribuer à l'amélioration de la qualité dans le domaine du logiciel, les 
experts internationaux se sont mis d'accord sur une base commune qui 


constitue une plate-forme normative. 


Ce référentiel normatif constitue notre point d'appui pour construire la 
qualité des produits logiciels que ces produits soient industrialisés (progiciels) 
ou le résultat de développements spécifiques personnalisés. 


1. Qualité, une exigence 
pour les technologies 
de l'information 


L'informatique est le domaine d'activité qui concerne le traitement 
de l'information par des équipements électroniques (ordinateurs). 
Ces traitements de l'information reposent sur deux éléments : 

—le matériel (hardware), composants électroniques, cartes et 
périphériques ; 

—le logiciel (software), ensemble d'instructions système ou 
applicatives pour l'acquisition, le stockage, la transformation, la 
transmission et la restitution automatique de données. 


Le logiciel est un produit industriel un peu particulier. Il se 
matérialise par des instructions de code sous la forme de don- 
nées implantées sur un support physique. 


Comme tout produit industriel il doit répondre à des besoins for- 
mulés par des clients/utilisateurs qui expriment des exigences. Le 
concept d’un produit prend naissance dans l'esprit des ingénieurs 
qui imaginent puis dessinent ses fonctionnalités. Ensuite, des déve- 
loppeurs le font passer de l'état de plan ou de maquette à l'état de 
produit manufacturé. C'est la notion de cycle de vie (processus). 

L'originalité du logiciel réside dans le fait qu'il s'agit d'un produit 
immatériel. On peut dire que c’est un produit du monde virtuel parce 
qu'invisible, par contre, ses effets sont, quant à eux, bien réels. 


Toutefois, dans le cadre des échanges fournisseurs-clients-utili- 
sateurs, le logiciel est rarement livré tout seul. Il est accompagné 
de documentation, de formation, d'assistance, de maintenance, 
voire d'exploitation, qui comportent des caractéristiques propres à 
la notion de service. L'assemblage des attributs produits et des 
attributs service conduit à utiliser de préférence le terme de pres- 
tations de services. 


La diversité des technologies de l'information, le grand nombre 
de textes normatifs qui s'y rattachent et la richesse des retours 
d'expérience, nous ont conduits à aborder ce thème de la qualité 
d'une manière segmentée. Ainsi, nous proposons une approche en 
trois parties. Chaque partie est couverte par un dossier qui 
constitue un angle de vision différent mais complémentaire. Le 
présent dossier développe la vision produit logiciel. 


2. Référentiels normatifs 
applicables 


Le logiciel, bien que produit relativement récent n'échappe pas 
au champ d'investigation des instances normatives internationales 
(ISO et AFNOR). 


PROCESSUS 
Nouvelle 


numérotation 
ISO/CEI 33000 


ISO/CEI 12207 
(Modèle) 


ISO/CEI 15504 
(Évaluation) 


ISO 9000 


(qualité) Nouvelle 


numérotation 
ISO/CEI 25000 


PRODUITS 


ISO/CEI 9126 
(Modèle) 


ISO/CEI 14598 - 
(Évaluation) 


Figure 1 - Cartographie normative pour le logiciel 


Les normes ISO 9000 relatives au management de la qualité sont 
applicables à tout organisme, donc aussi aux organismes qui 
conçoivent, fabriquent et vendent du logiciel, notamment en ce qui 


concerne leur certification. 


Mais les instances internationales ont aussi rédigé des normes 
spécifiques, adaptées pour le logiciel. Nous allons en résumer les 
principales. 


2.1 Cartographie normative 


Parmi les très nombreuses normes relatives au logiciel, les principales 
peuvent être classées selon deux grandes catégories fondamentales : 

— la catégorie des normes applicables aux processus d'ingénierie ; 

— la catégorie des normes applicables aux produits logiciels. 

La figure 1 résume graphiquement les principales normes que 
nous allons présenter et leur positionnement dans les catégories res- 
pectives. 

En complément de ces normes fondamentales, nous évoquons 
l'apparition des nouvelles séries 33000 pour les processus et 25000 
pour les produits logiciels. 

Il existe aussi deux autres séries de normes intéressantes que 
nous citons : 

— la série ISO/CEI 20000 qui concerne la qualité des prestations 
de services Information Technology ; 

— la série ISO/CEI 27000 qui concerne la sécurité de l'information. 


2.2 Organisation des dossiers 


Pour tenir compte de la segmentation de ces approches norma- 
tives pratiquées par les experts internationaux, la présentation des 
dossiers est la suivante : 


— un lot de trois dossiers orientés vers les études et réalisations 
informatiques : 


e processus d'ingénierie informatique [H 4 028v2], 
e produit logiciel [H 4 029], 
e gestion du cycle de vie du logiciel [H 4 031]; 
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— un dossier [H 3 280] qui traite de la maîtrise des prestations de 
service Information Technology (ISO/CEI 20000). Ce dossier est 
orienté vers la production des services informatiques et est intitulé 
ITIL et ISO 20000 ; 

- un dossier [H 5 070] qui traite de la maîtrise de la sécurité de 
l'information (ISO/CEI 27001). 


3. Norme ISO/CEI 9126 


3.1 Contexte 


Nous allons maintenant aborder les normes applicables aux 
trois catégories de produits logiciels suivants : 


- les produits développés sur mesures ; 

- les progiciels appelés aussi « logiciels sur étagère » ; 

— les logiciels embarqués, intégrés dans du matériel informa- 
tique (firmware). 


La qualité d'un produit logiciel doit être définie dès sa 
conception. Pour cela, des facteurs clés appropriés doivent être 
choisis. Des critères doivent prendre en compte les spécificités du 
produit logiciel à construire, les objectifs d'utilisation en fonction 
des technologies utilisées. Pour chaque critère retenu, un 
ensemble de métriques communément admises et validées doit 
permettre de vérifier la satisfaction de ces critères. 


Puis, au moment de la fabrication, des contrôles des niveaux de 
qualité doivent être définis et mis en place. Ces contrôles ont pour 
objectifs de s'assurer que le futur produit logiciel est en mesure de 
satisfaire aux critères définis dans le cahier des charges et retenus 
lors de la conception. 


Ensuite, c'est en utilisation (en mode tests d'abord puis en mode 


de fonctionnement réel) que l'atteinte des niveaux de qualité peut 
être mesurée et vérifiée. 


3.2 Structure normative 


En fait, il n'y a pas une seule norme ISO 9126 pour la qualité des 
logiciels mais un ensemble de plusieurs normes qui se 
complètent. 


Cet ensemble comprend quatre normes : 


— ISO 9126 partie 1 (version 1992) qui décrit les caractéristiques 
de qualité et les directives d'utilisation. Ce document a le statut de 
norme et existe en version francaise : 


Besoins des 
utilisateurs QUALITÉ 
en matière Cassin» DE 
de qualité FONCTIONNEMENT 
logicielle 
Exigences | 
de qualité Validation ——+| QUALITÉ EXTERNE 
externe 
Exigences l 
de qualité Vérification ———| QUALITÉ INTERNE 
interne 


Figure 2 - Différents niveaux de qualité d’un produit logiciel 


3.3.1 Qualité de fonctionnement 


Au niveau du fonctionnement, la norme élabore un modèle qua- 
lité qui correspond à l'effet combiné entre les six caractéristiques 
définies dans le 8 3.3.4. En cela, la qualité de fonctionnemet peut 
s'appuyer sur certaines métriques externes et parfois internes. De 
plus, afin de tenir compte de la perception ressentie par l'utilisa- 
teur, la norme complète le modèle par les quatre caractéristiques 
spécifiques : efficacité, productivité, sécurité, satisfaction définies 
dans le 8 3.3.5. En effet, la réalisation du produit doit satisfaire aux 
besoins de l'utilisateur. 


3.3.2 Qualité externe 


À ce niveau externe de la qualité, les métriques définies servent 
de cible pour la validation des différents stades de développement. 
Il convient que toutes les caractéristiques de qualité soient définies 
dans les spécifications à l'aide de métriques externes. Ces 
métriques découlent en partie des exigences des utilisateurs et 
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es logiciels libres ne constituent pas une technique comme la program- 

mation objet, ils ne sont pas écrits dans un langage de programmation parti- 
culier ou destinés à une plate-forme spécifique. Ce qui les définit est d'une autre 
nature : leur licence d'utilisation institue un régime de propriété sociale collec- 
tive, qui autorise chacun à accéder au code source, à l'utiliser comme il l'entend, 
à le modifier et à redistribuer le résultat de ces modifications. Par cette invention 
« juridique », les fondateurs des logiciels libres ont rendu possibles divers 
modèles de développement partagé des logiciels. Des réalisations de grande 
ampleur en ont résulté dans des domaines aussi divers que les systèmes 
d'exploitation, les interfaces graphiques, la technologie pour les médias, les logi- 
ciels embarqués ou le calcul en grappes et en grille. Des innovations spécifiques 
ont émergé ou ont été diffusées dans le cours de ce mouvement, qu'il s'agisse 
de supports au développement ou de fonctionnalités comme le partage de 
fichiers pair à pair. Le lecteur devra donc toujours garder à l'esprit qu'au-delà de 
telle ou telle réalisation remarquable (les logiciels supports d'Internet ou du 
Web, le système d'exploitation GNU/Linux et ses milliers d'applications, par 
exemple), c'est le mécanisme de création et de partage rendant possibles les 
logiciels libres qui mérite l'attention. 

À l'heure actuelle, un grand débat se développe à l'échelle mondiale : les logi- 
ciels libres sont-ils un modèle général, ayant vocation à s'étendre au moins à 
l’ensemble des plates-formes et des applications génériques, ou une simple 
curiosité sociétale destinée à des groupes d'usagers passionnés ? Ce débat a des 
dimensions politiques, sociales, culturelles et économiques qui échappent à un 
ouvrage encyclopédique technique. Mais il a aussi une dimension proprement 
technique. En donnant au lecteur une compréhension générale des mécanismes, 
réalisations, atouts et difficultés techniques des logiciels libres, cet article de 
synthèse vise à permettre à chaque lecteur de se faire sa propre opinion, et d’uti- 
liser au mieux les potentialités de ce domaine. 

Le contenu de cet article doit beaucoup au groupe de travail européen sur les 
logiciels libres - en particulier en ce qui concerne le paragraphe 1 dont plusieurs 
extraits sont simplement traduits ou adaptés de son rapport [1] - et aux contacts 
de l'auteur avec les développeurs et usagers d'Europe et d’ailleurs. Ils ne peu- 
vent être tous cités ici, mais l’article tout entier constitue un hommage à leur 
activité. Il y a aujourd'hui quelques centaines de milliers de développeurs de 
logiciels libres dans le monde, des dizaines de millions d'usagers conscients, et 
chacun de nous est usager à un titre ou un autre d'infrastructures et de normes 
qui n'existeraient pas sans les logiciels libres. 

Les opinions exprimées dans ce texte sont celles de l’auteur et ne représentent 
pas nécessairement le point de vue officiel de la Commission européenne. 
L'auteur maintient également une version en ligne de ce texte sous la « GNU 
Free Documentation License », version destinée à être amendée, complétée et 
mise à jour. 


1. Historique et motivation 


1.1 Préhistoire : logiciels de base 
des constructeurs 


Le rapport du groupe de travail européen sur les logiciels libres 
signale que les logiciels ont été « libres » bien avant qu'il n'existe de 
logiciels propriétaires, un fait aujourd'hui oublié du fait de la domi- 
nation des approches propriétaires dans les années 1980 et 1990. De 
fait, dans les années 1960, les constructeurs d'ordinateurs, au pre- 
mier rang IBM mais aussi Control Data, distribuaient les sources des 
logiciels de base de leurs ordinateurs, autorisaient les usagers à 
modifier pour leurs besoins ce code et, dans une certaine mesure, 
encourageaient la soumission en retour de ces modifications. Ce 
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mode de diffusion des logiciels ne faisait cependant pas l'objet 
d'une codification juridique et s'explique essentiellement par le fait 
qu'à l'époque, le matériel représentait l'essentiel de la valeur ajou- 
tée pour la filière informatique. Les développements logiciels inter- 
nes aux sociétés utilisatrices représentaient déjà des investis- 
sements importants, mais ne faisaient pas l'objet d'une diffusion 
commerciale. 


1.2 Les fondateurs : GNU, Berkeley et TEX 


C'est à partir du milieu des années 1970 qu'il devint usuel de dis- 
tribuer des logiciels seulement sous forme d'exécutables, et en res- 
treignant les droits d'usage et de modification. C'est cependant la 
repropriétarisation d'Unix qui déclencha le choc psychologique qui 
allait aboutir à l'émergence des logiciels libres comme mouvement 
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conscient. Développé aux AT&T Bell Labs en coopération étroite 
avec divers chercheurs de l'université de Berkeley, le système Unix 
était en effet utilisé par de vastes communautés de chercheurs uni- 
versitaires aux États-unis. La décision d'AT&T de ne plus diffuser 
librement le système d'exploitation mais de réclamer des droits de 
licence allait aboutir à la fragmentation du monde Unix, et convain- 
cre deux groupes distincts de la nécessité de garantir la disponibilité 
d'une infrastructure logicielle libre pour tout un chacun. 


Pour en savoir plus sur le système d'exploitation Unix, le lec- 
teur est invité à consulter l’article [H 1 528] qui lui est consacré. 


Richard Stallman qui était précédemment programmeur dans le 
laboratoire d'intelligence artificielle du Massachusetts Institute of 
technology (MIT), démissionna et lança le projet GNU (GNU is Not 
Unix) et la Free Software Foundation. Il s'agissait pour lui, dès le 
départ, de construire un système d'exploitation complet, qui soit 
librement utilisable et extensible par tout un chacun. Il commença 
par le développement d'outils de base (éditeur Emacs, compilateur 
gcc). Au-delà de ces réalisations techniques remarquables, sa 
contribution fondamentale fut la définition et la rédaction de la 
licence GNU General Public License (GPL) qui définit le régime de 
propriété sociale collective et les devoirs qui y sont attachés pour les 
logiciels libres. Sur le plan philosophique, Richard Stallman rédigea 
le manifeste de GNU et divers articles définissant les logiciels libres 
comme projet éthique et politique [2][3]. 


Projet GNU http://www.gnu.org/home.fr.html 


Sur la côte ouest des États-Unis, le groupe de recherche en infor- 
matique de l'université de Berkeley développait diverses amélio- 
rations du système Unix, bientôt connues sous le nom de Berkeley 
Software Distribution (BSD). Ces efforts étaient soutenus par un 
financement de la Defense Advanced Research Projects Agency 
(DARPA) aux États-Unis, et recevaient l'assistance d'un vaste réseau 
d'usagers et de programmeurs dans le monde entier. La distribution 
de BSD était cependant restreinte aux possesseurs d'une licence 
AT&T Unix dont certains composants propriétaires essentiels 
comme le noyau du système d'exploitation étaient nécessaires pour 
pouvoir utiliser BSD. 


Le développement du système de traitement de texte et d'édition 
mathématique TEX à l'initiative de Donald Knuth constitue un pré- 
curseur non moins important puisqu'il préfigure les logiciels libres 
d'application. Très rapidement, une communauté d'usagers scienti- 
fiques se forma, et ce logiciel enrichi de nombreux utilitaires et inter- 
faces constitue aujourd'hui l’une des bases essentielles de l'édition 
scientifique. 


1.3 Infrastructure des réseaux : Arpanet, 
Internet et Usenet 


Le développement du réseau Arpanet [4][5], précurseur du réseau 
Internet, commença bien avant que ne soit formalisée l'idée des 
logiciels libres, puisqu'on peut en situer l'impulsion initiale à l'arri- 
vée de J. Licklider à l'Advanced Research Project Agency en 1962, et 
que son véritable développement eut lieu de 1967 à 1971. C'est sa 
philosophie et l'organisation du développement des technologies 
liées à ce réseau qui justifient de lui donner une place importante 
dans l'histoire des logiciels libres. Dès le départ, Licklider organisa le 
développement du réseau comme création d'une communauté de 
développeurs et d'usagers. Le groupe de chercheurs concernés se 
donna les moyens de produire en commun et de façon progressive 
les spécifications de leur travail, à travers l'usage des « Requests for 
Comments » (RFC), véritables précurseurs de la documentation 
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libre. On peut dire que ces chercheurs inventèrent un modèle de 
développement proche de celui des logiciels libres avant que ceux- 
ci existent. La rencontre avec les logiciels libres proprement dits ne 
se produisit qu'au début des années 1980. Le protocole de réseau 
NCP qui sous-tendait Arpanet se révélant inadapté au développe- 
ment du nombre d'usagers du réseau, un nouvel ensemble de pro- 
tocoles, TCP/IP [6] fut développé et formalisé dans les années 1970 
pour aboutir en 1981 à la version aujourd'hui encore dominante IP 
v.4. C'est l'inclusion des logiciels implémentant ces protocoles (en 
particulier la IP Protocol Stack, ou bind, qui assure la correspon- 
dance entre noms de domaine et adresses IP) dans la Berkeley 
Software Distribution en 1983 qui en assura la diffusion rapide. 


Pour en savoir plus sur l'architecture TCP/IP le lecteur est 
invité à consulter l’article [H 2 288] qui lui est consacré. 


Ce sont aujourd'hui des logiciels libres qui sous-tendent le fonc- 
tionnement des éléments essentiels de l'infrastructure logicielle 
d'Internet. Mais on peut dire qu'Internet a bien rendu aux logiciels 
libres ce qu'ils lui ont donné. Car c'est grâce à Internet, et en parti- 
culier au protocole de transfert de fichier FTP et au protocole de 
courrier électronique SMTP. que le développement de logiciels 
libres a pu s'étendre mondialement, et bénéficier de tous les avan- 
tages de la coopération à grande échelle. 


Un autre élément qui favorisa le développement des logiciels 
libres et de leurs mécanismes de coopération fut l'apparition des 
groupes de discussion Usenet [7]. Le développement de ces grou- 
pes de discussion fut initié dès 1979 sur la base du protocole UUCP 
d'Unix, mais ils prirent un essor significatif sur la base du Network 
News Transfer Protocol (NNTP) d'Internet en 1986. En permettant la 
discussion entre un très grand nombre d'usagers du monde entier 
de toutes sortes de questions, l’aide coopérative pour la résolution 
de problèmes techniques en particulier, ils constituèrent une base 
pour l'élaboration et la diffusion des logiciels libres. 


1.4 GNU/Linux, 386BSD), les distributeurs 


Pendant les années 1980 et 1990, le développement des logiciels 
libres continua, principalement à travers de petits groupes de déve- 
loppeurs. Une intégration progressive de ces logiciels eut lieu, qui 
aboutit à la création d'environnements complets, mais s'exécutant 
sur des systèmes Unix toujours propriétaires. La qualité de certains 
de ces outils conduisit à une utilisation croissante par les adminis- 
trateurs de réseaux et les développeurs. 


C'est en 1991-1992 qu'une étape décisive fut franchie avec la dis- 
ponibilité de deux systèmes d'exploitation complets libres. En Fin- 
lande, un étudiant de l'Université technique d'Helsinki, Linus 
Torvalds, implémenta un noyau particulièrement compact de sys- 
tème d'exploitation qu'il baptisa Linux, et le diffusa sous la licence 
GPL. Joint à l'ensemble d'outils et d'utilitaires développé par le pro- 
jet GNU (qui travaillait à la production d'un autre noyau), le noyau 
Linux rendit disponible un système complet, souvent baptisé sim- 
plement Linux, mais qu'il est plus correct d'appeler GNU/Linux pour 
prendre en compte la réalité des contributions. 


En parallèle, Bill Jolitz implémenta les éléments manquant à la 
distribution produite à Berkeley sous le nom de Net/2 et dont le but 
était d'aboutir à une version de BSD Unix qui soit libre de tout copy- 
right d'AT&T. Ces efforts aboutirent au système 386BSD, destiné aux 
processeurs de la classe i386 d'Intel. Ce système fut diffusé sous la 
licence BSD, une licence libre sans clause de copyleft (8 2.2), et 
incluait des logiciels libres sous d’autres licences comme le compi- 
lateur gcc sous licence GPL. 


Pour en savoir plus sur le système Linux, le lecteur est invité à 
consulter l’article [H 1 538] qui lui est consacré. 
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En 1993, GNU/Linux et 386BSD (qui donna naissance à toute une 
série de systèmes d'exploitation comme NetBSD, FreeBSD et Open 
BSD) étaient devenus des plates-formes de qualité. Les systèmes 
BSD furent diffusés essentiellement à travers les réseaux d'usagers 
des anciens systèmes Unix, alors que GNU/Linux donna naissance 
à une nouvelle catégorie d'acteurs : les distributeurs, des sociétés 
ou efforts associatifs comme Slackware, Debian, RedHat, SUSE, 
Mandrake, etc. Par ce biais, les systèmes d'exploitation libres attei- 
gnirent de nouvelles catégories d'usagers, mais tout en restant 
confinés à une population encore assez réduite. 


1.5 Par et pour le Web 


Tout comme pour Internet, les « moteurs » du Web ont été et sont 
encore en grande partie des logiciels libres. La «Toile » le leur a bien 
rendu, car les sites Web permettent de nouvelles formes d'héberge- 
ment de projets et de développement coopératif, et les moteurs de 
recherche ont donné une nouvelle réalité à l'accessibilité immédiate 
globale des logiciels et des informations les concernant. 


Les premiers logiciels de base (implémentations du protocole 
HTTP, serveur du CERN puis de NCSA) étaient des logiciels libres. 
L'ensemble des implémentations de référence produites par le W3C, 
le World Wide Web Consortium, sont des logiciels libres, tout comme 
de remarquables navigateurs comme Konqueror (KDE sous GNU/ 
Linux). Mais ce sont deux logiciels particuliers qui justifient une 
mention spéciale. Le serveur Web Apache fut le premier logiciel libre 
à devenir le « produit » dominant pour une application essentielle 
(plus de 50 % des serveurs). Son développement est organisé au 
sein de l'Apache Software Foundation et il est diffusé sous une 
licence semblable à la licence BSD. En 1998, la société Netscape fai- 
sait face à une offensive de Microsoft utilisant sa position dominante 
dans les systèmes d'exploitation pour conquérir un nouveau mono- 
pole en matière de navigateurs Web pour son logiciel Internet Explo- 
rer. Netscape décida de « libérer » les sources de son navigateur 
sous le nom de Mozilla. Bien qu'il y ait eu des précurseurs moins 
connus, c'est cette décision qui marqua la naissance de nouvelles 
stratégies industrielles utilisant les logiciels libres pour tenter de 
contrer les tendances monopolistiques des logiciels propriétaires. 


1.6 Interfaces graphiques 
et applications génériques 


À l'origine, les systèmes d'exploitation libres étaient peu déve- 
loppés sur le plan des interfaces graphiques. Or c'est précisément 
un environnement graphique destiné aux systèmes Unix, le X Win- 
dows System, qui fut l’un des premiers logiciels libres dont le déve- 
loppement (au MIT) fut financé par un consortium de sociétés 
privées. L'existence de cette base sous licence libre permit le déve- 
loppement rapide de XFree86, le plus utilisé des serveurs d'inter- 
faces graphiques implémentant le protocole X11, rapidement étoffé 
d'une foule de gestionnaires de fenêtres. Dans la seconde moitié 
des années 1990, GNOME et KDE, deux projets concurrents et pro- 
gressant à une vitesse remarquable, développèrent deux environne- 
ments graphiques complets, y compris des bibliothèques et des 
outils de développement, et bientôt un ensemble associé d'appli- 
cations génériques. Ils furent perçus initialement comme de simples 
imitations des interfaces Windows, mais il devint très vite évident 
que leur portée allait bien au-delà, et que leur conception moderne 
et centrée sur la facilité de développement de nouvelles applications 
était réellement innovante. Ces logiciels furent aussi les premiers du 
monde libre à atteindre une qualité de finition esthétique et de faci- 
lité d'apprentissage pour des usagers non développeurs, ce qui joua 
un rôle important dans la diffusion des logiciels libres à partir de 
1998 au-delà de leurs cercles habituels d'usagers. 
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1.7 Le logiciel libre coté en bourse 


En 1998, les logiciels libres attirèrent soudain l'attention de cercles 
bien différents des militants associatifs et des chercheurs universi- 
taires. Ce fut le produit conjoint des premières stratégies industriel- 
les déjà mentionnées et d'un effort de communication entrepris par 
les créateurs de l'Open Source Initiative. Sous l'impulsion principale 
d'Eric Raymond et de Bruce Perens, ses fondateurs voulurent déga- 
ger les logiciels libres de leur association avec un projet militant ou 
éthique, et corriger en même temps une ambiguïté propre à 
l'anglais free qui signifie à la fois « libre » et « gratuit ». Ils forgèrent 
l'expression « open source » qui connut un grand succès en anglais, 
tout en continuant à être rejetée par ceux qui craignent que pour 
corriger une ambiguïté, on ait introduit une confusion bien plus 
grande en donnant à penser que les logiciels libres peuvent être 
considérés comme une simple commodité ou un modèle de déve- 
loppement, sans que la motivation de liberté et de partage social 
n'importe. Bien des polémiques ont suivi, mais il faut noter qu'en 
pratique, ceux qui se reconnaissent plus dans le free software et 
ceux qui préfèrent l’open source software coopèrent quotidienne- 
ment, utilisent leurs productions réciproques, et constituent un con- 
tinuum d'acteurs solidaires, face par exemple aux attaques des 
sociétés productrices de logiciels propriétaires. 


Open Source Initiative http:/{www.opensource.org 


En 1999, le monde financier, en particulier aux États-Unis, com- 
mença à prêter attention aux logiciels libres, et les premières intro- 
ductions en bourse (RedHat, VA Linux) eurent lieu. Comme les 
investissements industriels se développaient en parallèle, cela 
entraîna un afflux de ressources qui permis à certains projets 
d'atteindre une taille sans précédent. Le reflux lié à l'effondrement 
des sociétés de commerce sur Internet en 2001 toucha moins les 
sociétés de logiciels libres que d'autres acteurs informatiques. En 
Europe, au moment de la rédaction de cet article, seule la société 
Mandrakesoft est cotée en bourse. 


Le nombre d'usagers des systèmes d'exploitation libres com- 
mença à se chiffrer en dizaines de millions dans le monde, et les 
parts de marché pour les serveurs devinrent très significatives. Plus 
généralement, on commença à se demander si les logiciels libres 
pouvaient constituer le futur de l'économie du logiciel (8 6.2). 


1.8 Investissements industriels 
et communautés scientifiques 


À partir de 1999, diverses sociétés ont fait le choix stratégique 
d'investir dans la constitution de logiciels libres, considérant que la 
valeur ajoutée se situerait dans l’avenir soit sur le matériel, soit sur- 
tout sur les services de réalisation et d'adaptation de solutions infor- 
matiques utilisant une base de logiciels libres. IBM, profitant de son 
double statut de constructeur et de société de services, est au pre- 
mier rang de ses investissements, affectant chaque année des cen- 
taines d'ingénieurs au portage et au renforcement de GNU/Linux 
sur ses machines, mais aussi au développement d'outils de déve- 
loppement de logiciels libres à travers la plate-forme Eclipse. Sun 
(pour la suite bureautique Open.Office et les logiciels de middle- 
ware (intergiciels)) et Hewlett-Packard (intergiciels, pilotes d'impri- 
mante) ont également développé des stratégies, tout comme Nets- 
cape, déjà mentionné, et Apple qui a entamé un vaste 
rapprochement vis-à-vis du monde des logiciels libres à travers le 
choix du système d'exploitation X, dérivé de BSD. En Europe, Nokia 
reste la seule société importante à avoir développé une stratégie 
libre explicite autour du Nokia MediaTerminal, mais des sociétés ini- 
tialement plus réticentes comme Alcatel etThalès considèrent main- 
tenant les logiciels libres comme un paramètre essentiel de leurs 
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stratégies. Les sociétés spécialisées dans les logiciels libres sont 
dans une situation paradoxale. Mis à part RedHat (qui a incorporé 
Cygnus en 1999), les sociétés de taille moyenne éprouvent certaines 
difficultés à devenir ou à rester durablement profitables. À l'opposé, 
un tissu très important de petites sociétés de services et de support 
spécialisés est florissant, en particulier en Europe : plus de 50 socié- 
tés de ce type existaient en France en 2001 [8]. 


En parallèle avec ces investissements industriels qui apportent 
une crédibilité importante aux logiciels libres, dans de nombreuses 
disciplines scientifiques (biotechnologie, astrophysique), on assiste 
à la production par des communautés mondiales de chercheurs 
d'une infrastructure de logiciels libres pour leur discipline. Ces 
efforts consistent souvent à produire en parallèle des bases de don- 
nées gigantesques en contenus libres (8 1.10) et les logiciels servant 
à gérer et à exploiter ces données. 


1.9 Étapes récentes : logiciels insérés, 
calcul pair à pair et grilles de calcul, 
plates-formes de création artistique 


Pour beaucoup, les logiciels libres restent aujourd’hui synonymes 
de systèmes d'exploitation pour les ordinateurs personnels ou 
d'imitations d'applications propriétaires. Cette vision restrictive fut 
toujours fausse et l'est plus que jamais. Des systèmes d'exploitation 
libres pour les logiciels insérés (embarqués) existent aujourd'hui 
dans les applications industrielles les plus exigeantes (d'eCos aux 
diverses extensions temps réel de Linux). Des applications parti- 
culièrement innovantes comme celles du calcul pair à pair et de ses 
applications au partage et à la production coopérative de données 
doivent tout aux logiciels libres et à leurs usagers (la version initiale 
de Napster, mais aussi Gnutella et de très nombreux autres déve- 
loppements). Les centres de création artistique contemporaine 
s'orientent de plus en plus vers la production coopérative de plates- 
formes de création et logiciels libres . 


Exemple : citons les travaux du réseau de centres de recherche V2 
Platform aux Pays-Bas ou la diffusion en logiciels libres des travaux 
issus de centres de création et de recherche musicale (IRCAM, Univer- 
sitat Pompeu Fabra de Barcelone, KTHStockholm, centre Tempo Reale 
de Florence au sein du projet européen AGNULA (8 3.4). 


Enfin, les grilles de calcul (grid computing), qui visent à fournir 
aux scientifiques et aux ingénieurs un accès transparent aux res- 
sources de calcul et de stockage de données distribuées dans le 
monde entier, sont tout entières construites autour de logiciels 
libres (voir notamment l’intergiciel Globus et les activités du Global 


2. Licences, droits 
et obligations 


Un logiciel est libre s’il est diffusé sous une licence libre. Les licen- 
ces de logiciels libres ont en commun d'accorder à leurs usagers un 
ensemble de droits fondamentaux, décrits dans le paragraphe 2.1. 
Elles diffèrent entre elles sur la définition de certaines obligations 
associées à ces droits (8 2.2 et 8 2.3). Le paragraphe 2.4 situe briève- 
ment les logiciels libres par rapport à différents instruments qu'il est 
d'usage de réunir sous le terme de « propriété intellectuelle ». 


2.1 Droits fondamentaux 


Toute licence libre accorde à toute personne morale ou phy- 
sique : 

— la liberté d'exécuter le logiciel pour tout usage ; 

— la liberté d'étudier le fonctionnement du logiciel et de 
l'adapter à ses besoins ; 

— la liberté de redistribuer des copies du programme ; 

— la liberté de modifier le programme et de publier ces modi- 
fications. 

Dans le vocabulaire de l'Open Source Initiative, ces libertés 
sont définies de façon similaire : droits d'accéder au code source, 
de l'utiliser, de le redistribuer et de le modifier. 


Si une seule des libertés fondamentales du logiciel libre vient à 
manquer dans la licence qui définit ses termes d'usages, il ne sau- 
rait prétendre être un logiciel libre et il est probable que ce soit tout 
le processus de développement et d'usage qui en soit affecté. 
Cependant, les différentes licences libres associent fréquemment 
des obligations à l'exercice de ces droits, dans le but même de pré- 
server les libertés qui forment leur objectif. 


2.2 Noyau de la GPL et obligations 


La GNU General Public License fut la première licence libre et elle 
couvre aujourd'hui une part très importante des logiciels libres. Sa 
spécificité est de mettre en œuvre un principe appelé copylefting 
(jeu de mot sur copyright), qui soumet le fait de bénéficier des ter- 
mes de la licence à l'acceptation de redistribuer tout logiciel dérivé 
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ans le domaine du logiciel et plus généralement pour tout ce qui concerne 

les systèmes d'information, la recherche de la qualité est la préoccupation 
de tous les acteurs. Toutefois, le manque de temps, la valse des évolutions 
technologiques, et les contraintes de tous ordres, semblent reléguer les aspi- 
rations de qualité au rang des objectifs inaccessibles et des mythes. 


Pourtant, la qualité se résume simplement à la satisfaction des clients et par 
extension à l'atteinte de la satisfaction des exigences de tous les partenaires 
qui interviennent dans une opération ou un projet (utilisateurs, décideurs, 
organisateurs, acheteurs, chef de projet, concepteurs, développeurs, testeurs, 
exploitants, etc.). 

Bien qu'immatériel, le logiciel n'échappe pas à ce principe fondamental. Afin 
de contribuer à l'amélioration de la qualité dans le domaine du logiciel, les 
experts internationaux se sont mis d'accord sur une base commune qui 
constitue une plate-forme normative. 


Ce référentiel normatif constitue notre point d'appui pour construire la 
qualité des processus d'ingénierie de projet ou d'exploitation, mais aussi la 
qualité de livrables : produits logiciels et les prestations qui les accompagnent. 
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1. Qualité, une exigence 
pour les technologies 
de l'information 


L'informatique est le domaine d'activité qui concerne le traitement 
de l'information par des équipements électroniques (ordinateurs). 
Ces traitements de l'information reposent sur deux éléments : 


—le matériel (hardware), composants électroniques, cartes et 
périphériques ; 

—le logiciel (software), ensemble d'instructions système ou 
applicatives pour l'acquisition, le stockage, la transformation, la 
transmission et la restitution automatique de données. 


Le logiciel est un produit industriel un peu particulier. Il se 
matérialise par des instructions de code sous la forme de don- 
nées implantées sur un support physique. 


Comme tout produit industriel, il doit répondre à des besoins for- 
mulés par des clients/utilisateurs qui expriment des exigences. Le 
concept d’un produit prend naissance dans l'esprit des ingénieurs 
qui imaginent puis dessinent ses fonctionnalités. Ensuite des déve- 
loppeurs le font passer de l’état de plan ou de maquette à l'état de 
produit manufacturé. C'est la notion de cycle de vie (processus). 


L'originalité du logiciel réside dans le fait qu'il s’agit d'un produit 
immatériel. On peut dire que c'est un produit du monde virtuel 
parce qu'invisible. Par contre ses effets sont quant à eux bien réels. 


Toutefois, dans le cadre des échanges fournisseurs-clients-utilisa- 
teurs, le logiciel est rarement livré tout seul. Il est accompagné de 
documentation, de formation, d'assistance, de maintenance voire 
d'exploitation, qui comportent des caractéristiques propres à la notion 
de service. L'assemblage des attributs produits et des attributs service 
conduit à utiliser de préférence le terme de prestations de services. 


La diversité des technologies de l'information, le grand nombre 
de textes normatifs qui s'y rattachent et la richesse des retours 
d'expérience, nous ont conduits à aborder ce thème de la qualité 
d'une manière segmentée. Ainsi, nous proposons une approche en 
trois parties. Chaque partie est couverte par un dossier qui 
constitue un angle de vision différent mais complémentaire. Après 
avoir abordé la vision processus d'ingénierie et la vision produit 
logiciel, le présent dossier développe la vision des bonnes 
pratiques opérationnelles à mettre en œuvre. 


2. Référentiels normatifs 
applicables 


Le logiciel, bien que produit relativement récent n'échappe pas 
au champ d'investigation des instances normatives internationales 
(L'ISO et l’'AFNOR). 


Les normes ISO 9000 relatives au management de la qualité sont 
applicables à tout organisme, donc aussi aux organismes qui 
conçoivent, fabriquent et vendent du logiciel, notamment en ce qui 
concerne leur certification. 


Mais les instances internationales ont aussi rédigé des normes 
spécifiques, adaptées pour le logiciel. Nous allons en résumer les 
principales. 


2.1 Cartographie normative 
Parmi les très nombreuses normes relatives au logiciel, les prin- 


cipales normes peuvent être classées selon deux grandes catégo- 
ries fondamentales : 


PROCESSUS 
Nouvelle 


numérotation 
ISO/CEI 33000 


ISO/CEI 12207 ISO/CEI 15504 
(Modèle) (Évaluation) 


ISO 9000 
(qualité) 

PRODUITS Nouvelle 
numérotation 


ISO/CEI 25000 


ISO/CEI 9126 
(Modèle) 


ISO/CEI 14598 ] 
(Évaluation) 


Figure 1 - Cartographie normative pour le logiciel 


— la catégorie des normes applicables aux processus d'ingénierie ; 
— la catégorie des normes applicables aux produits logiciels. 


La figure 1 résume graphiquement les principales normes que 
nous allons présenter et leur positionnement dans les catégories 
respectives. 


En complément de ces normes fondamentales nous évoquerons 
l'apparition des nouvelles séries 33000 pour les processus et 25000 
pour les produits logiciels. 


Il existe aussi deux autres séries de normes intéressantes que 
nous citons : 

— la série ISO/CEI 20000 qui concerne la qualité des prestations 
de services Information Technology ; 

— la série ISO/CEI 27000 qui concerne la sécurité de l'information. 


2.2 Organisation des dossiers 


Pour tenir compte de la segmentation de ces approches norma- 
tives pratiquées par les experts internationaux, la présentation des 
dossiers est la suivante : 

— un lot de trois dossiers orientés vers les études et réalisations 
informatiques : 


e processus d'ingénierie informatique [H 4 028v2], 
e produit logiciel [H 4 029], 
e gestion du cycle de vie du logiciel - Bonnes pratiques [H 4 031]; 


— un dossier [H 3 280] qui traite de la maîtrise des prestations de 
service Information Technology (ISO/CEI 20000). Ce dossier est 
orienté vers la production des services informatiques et est intitulé 
ITIL et ISO 20000 ; 

- un dossier [H 5 070] qui traite de la maîtrise de la sécurité de 
l'information (ISO/CEI 27001). 


3. Cycle de vie de l'ingénierie 
du logiciel 


Un logiciel est un ensemble complexe et son développement 
nécessite une diversité d'activités. Or, pour maîtriser la complexité 
d'un ensemble, une technique efficace consiste à le subdiviser en 
plusieurs parties pour rendre cet ensemble contrôlable. Il est donc 
essentiel de structurer l'approche qualité du logiciel. En outre, la 
représentation du monde réel implique une action d'abstraction qui 
conduit vers l'emploi d'un modèle. Ainsi, la modélisation ou réduc- 
tion du monde réel, introduit la notion d'activités successives, d'où 
le concept de « cycle de vie ». Cette modélisation est commode et 
doublement utile. Elle permet une représentation graphique et logi- 
que et, de plus, offre une structure autour de laquelle les activités 
d'assurance qualité peuvent être construites et suivies. 


La vie d'un logiciel ou de système d'information va se décomposer 


en phases caractéristiques qui représentent des ensembles homo- 
gènes d'activités qu'il va falloir placer sous assurance qualité. 
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L'apport de bonnes pratiques professionnelles, issues de l'expérience, 
va nous y aider et nous faire gagner un temps précieux. Le phasage 
du cycle de vie va concerner : 

— la naissance du besoin ; 

— les exigences des utilisateurs ; 

— le développement ; 

- l'exploitation ; 

— la maintenance ; 

— le retrait. 


Demande 
(nouveau 
besoin) 


Exigences Développement 


La figure 2 représente l'enchaînement de ces grandes phases du 


cycle de vie du logiciel. Exploitation 


L'ingénierie de projet logiciel concerne principalement la phase 
de développement ; c'est cette phase que nous étudions en détail. 


Il existe plusieurs modèles de cycle de vie qui correspondent à Maintenance 
des problématiques différentes [1] : 
— en cascade ; 
-en«V»; 
- développement par prototypage ; 
— en cascade avec extensions successives ; 
— incrémental ; 


— en spirale. 


Retrait 


Figure 2 - Cycle de vie du logiciel 


Toutefois, dans la pratique, il s'avère souhaitable d'effectuer un Exemple 
assemblage en empruntant respectivement à chaque modèle les 
propriétés qui sont pertinentes pour le projet. Ainsi, d’une manière 
générale il est retenu : 


La figure 3 donne un exemple d'enchaînement des étapes du cycle 
de vie pour le développement d'un logiciel de gestion. Cet exemple 
pratique en forme de « Y » s'appuie sur une synthèse de modèles. Il 


- les avantages du modèle en « V » pour synchroniser les tests est important de noter les trois niveaux de contrôle par rapport au 
avec les spécifications ; plan de test, au plan d'intégration et au plan de validation. Chacun de 

—les avantages du modèle incrémental en raison de la ces contrôles permet de «donner confiance » entre les deux 
décomposition en sous-ensembles. branches droite et gauche du graphe « Y ». 


Spécification Logiciel prêt 
des exigences pour le service 
Mise en 
service 
Développemént de logiciel Test d'exploitation 
Î Logiciel accepté 
Définition À 
spécification Contrôle par rapport au plan de validation Test d'acceptation 
fonctionnelle (réception) 
z . de Logiciel testé 
Implémentation du logiciel Î 4 
un Contrôle par rapport Test complet 
. au plan d'intégration du logiciel 
Conception 
générale i 
Intégration 
du logiciel 
Are dsnnemes en s mb er dd snnn eme ne tn inde esene see Moss M nent 
! Y E 
' Spécification Construction Composants ! 
| de composant de composant testés : 
: de logiciel I ï 
' Li : 
' Conception Contrôle par rapport Intégration ï 
i pénales “fronts de composant ' 
i détaillée au plan de testes ! 
ï et test E 
! ' Spécification Codage module 1 
1 i de module et test unitaire 1 oi 
Figure 3 - Exemple de modèle en « Y » 
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Provenance 
des exigences 


INITIALISATION 


SPÉCIFICATIONS | CONCEPTION ] 


Processus 


Passage vers 
l'exploitation 


Plan d'Assurance Qualité Logiciel PAOL 
Plan de Développement Logiciel PDL 


RÉALISATION | RECETTE | 


d'ingénierie 


|| 


Livrable 
Livrable 


Livrable 


Fa 


Dossier expression 
des besoins 
(cahier des charges) 


L— 


Dossiers conception 
générale et détaillée 


DOSSIERS D'ÉTUDES 


Livrable 
= 


Dossier de programmes 
Tests techniques 


Dossier 
de recette 


Figure 4 - Étapes du développement 


La figure 4 représente l'application des principes de la qualité à 
la phase du développement du logiciel. À savoir, chacune des 
étapes du cycle de vie de notre modèle représentant : 

— d'une part la vision des processus d'ingénierie qui les composent ; 

—et d'autre part les livrables fournis au titre des produits 
(composants logiciels et composants documentaires). 


4. Étape 1 : initialisation 
d'un projet/planification 


4.1 Processus 


L'initialisation du projet est matérialisée par la rédaction et la 
diffusion d'une note de lancement. 


Si son importance le nécessite, le projet va être décomposé en 
plusieurs lots, chaque lot comportant un certain nombre d'étapes. 
Chaque étape contient des travaux à exécuter selon un certain 
ordre. La planification consiste à en organiser le séquencement. La 
planification est réalisée suivant deux axes : 

—une vue organisation de la qualité, dont les résultats des 
travaux d'étude sont consignés dans le document Plan d'assu- 
rance qualité logiciel (PAQL) ; 

— une vue évaluation initiale du projet (véritable devis du projet), 
dont les résultats des travaux d'étude sont consignés dans le 
document Plan de développement logiciel PDL. 


La figure 5 représente cette double vision de la planification de projet. 


4.2 Livrables 


4.2.1 Note de lancement 


La note de lancement est rédigée par la direction de la maîtrise 
d'ouvrage d'un projet qui fait connaître officiellement sa volonté et 


Vue _ 


Plan de 
développemen 


Vue 
Plan assurance 
qualité 


Figure 5 - Planification de projet logiciel 


sa décision d'engager le projet concerné. Ce document rappelle les 
objectifs et les contours du projet lancé. Il doit impérativement 
comporter l'identification du responsable qui a été choisi pour 
diriger les opérations et les moyens qui lui sont alloués pour réussir 
la mission confiée. 


4.2.2 Plan qualité logiciel ou plan d'assurance 
qualité logiciel (PAQL) 


Le Plan d'assurance qualité logiciel décrit les dispositions 
spécifiques prévues par l’organisation ou l'entreprise afin d'obtenir 
les niveaux de qualité requis pour le produit logiciel ou le service à 
construire dans le cadre du projet en question. Il est rédigé par le 
responsable du projet en s'inspirant du modèle donné par la 
norme française Z67-130. 
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Plan qualité logiciel 


Problématique 

Périmètre d'intervention 
Démarche de projet 
Structures organisationnelles 
Terminologie/vocabulaire 
Modalités de fonctionnement 


Règles prévues pour supporter les évolutions ultérieures du 
PAQOL 


4.2.3 Plan développement logiciel 


Le plan développement logiciel PDL décrit les dispositions 
prévues pour développer (concevoir, réaliser et tester) le(s) 
produit(s) logiciel(s) objet du projet. Il est rédigé par le responsable 
du projet. Il doit notamment préciser comment sont pris en 
compte les événements porteurs de changement, les procédures 
permettant de corriger les éventuelles anomalies et les principales 
zones de risques prévisibles avec les responsabilités de chacun 
des intervenants au projet. 


Plan développement logiciel 


Description des composants techniques et documents à réa- 
liser 


Moyens à mettre à disposition (charges, coûts, planning) 
Outils requis (méthodes, techniques et outils logiciels) 
Découpage en phases et les tâches afférentes à chaque phase 
Supports de suivi et d'avancement 

Moyens utilisés pour gérer le projet 


5. Étape 2 : spécifications 


5.1 Processus 


Cette étape de spécifications comporte l'étude et la prise en 
compte des exigences fonctionnelles (attentes) et des contraintes 


facilement saisissables car ils sont exprimés. Par contre les besoins 
implicites, invisibles par définition, sont souvent les plus impor- 
tants, lourds de conséquences et les plus complexes à appréhender. 

Les spécifications du futur système comprennent une architec- 
ture générale du fonctionnement du système projeté avec les 
liaisons entre les fonctions. Chaque fonction et sous-fonction est 
décrite. Une description de fonction comporte : les entrées, les 
sorties, les principaux traitements, les règles de gestion et les 
blocs de données manipulées. 


Dossier de définition des besoins 


Observation de l'état actuel de l’organisation (analyse de 
l'existant) 


Projection des spécifications pour répondre aux exigences 
(système cible) 


Contraintes 
Solution(s) possible(s) pour atteindre la cible (transformation) 
Justification des choix retenus 


5.2.2 Dossier de tests de validation (recette) 


En parallèle à l'étude des principales fonctions, l'équipe de 
projet s'attache à recueillir des éléments en vue de la recette utili- 
sateur. Pour chaque fonction retenue, on identifie les critères 
d'acceptation correspondants. Ces critères permettent d'apprécier, 
pendant les tests de validation (qualification métier), si les exi- 
gences des utilisateurs, exprimées dans le dossier de définition 
des besoins, sont satisfaites. Les travaux de gestion que les utilisa- 
teurs réalisent dans l'exercice de leur métier doivent être couverts. 
Les contrôles fonctionnels et des formules de calcul de gestion 
doivent produire des résultats exacts, vérifiables. C'est le moyen 
de contrôler que dans des conditions normales, proches de l'envi- 
ronnement réel, le système logiciel réagit convenablement. 


Dossier de tests de validation 


Plans de tests définissant et organisant le séquencement 
des actions 


Planification de ces actions 
Liste des scénarios métier formalisés et ordre de leur passage 
Pour chaque test : 


— fanrctinne à tacter 


La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 


Si vous souhaitez accéder au contenu intégral de cette base documentaire, rendez-vous 


à la fin de ce document. 


Et pour toute question sur nos offres d'abonnement, n'hésitez pas à contacter le service 
Relation clientèle au 01 53 35 20 20 ou par email à l'adresse infos.clients@teching.com. 
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L ‘information constitue un capital très important pour tout organisme. Elle 
représente une ressource vitale pour exercer des activités. À ce titre, 
l'information nécessite la mise en place et la gestion d'une protection adaptée. 


La sécurité de l'information a pour objectif de protéger l'information contre 
de nombreuses menaces qui pèsent sur la dégradation ou l'interruption de la 
continuité de l'activité de l'organisme. Des mesures doivent être définies, 
mises en œuvre, suivies, réexaminées et améliorées afin d'atteindre un certain 
nombre d'objectifs dédiés à la sécurité. 

Des processus particuliers doivent être définis et déployés pour y parvenir. 
Toutefois, ces derniers doivent s'intégrer harmonieusement avec les autres 
processus dans le cadre du système de management global de l'organisme. 

Afin de préciser les exigences de sécurité relatives à l'information, un réfé- 
rentiel normatif a été élaboré. Bien évidemment, il est applicable aux différents 
systèmes qui traitent l'information. 
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1. Sécurité, une exigence 
pour l'information 


Un système d'information se compose de processus, de 
systèmes et de réseaux, ensembles complexes qui permettent 
de traiter l'information. 


De nombreuses menaces pèsent sur les organismes quel que 
soit leur type d'activité. Plus les moyens technologiques de 
traitement sont sophistiqués et plus la probabilité de menace est 
élevée et sa détection difficile à réaliser. Les sources de menace 
sont très variées: fraude informatique, espionnage, sabotage, 
accès non autorisé, usurpation d'identité, attaque de site, virus, 
chevaux de Troie, vandalisme, incendie, inondation, panne de 
matériel, déni de service, vol de données... 


Toutes ces vulnérabilités avec leur cortège de conséquences 
néfastes engendrent la peur mais aussi peuvent conduire à des 
situations dramatiques, jusqu'à mettre en danger la survie de 
l'organisme. Y faire face est une nécessité qui incite à la prudence. 


Le besoin de sécurité correspond à la recherche de situations 
présentant un minimum de risque. La sécurité donne confiance car 
elle développe le sentiment d'être à l'abri de tout danger. 


La conception et la mise en place de mesures de protection adap- 
tées ne doivent pas se limiter aux moyens techniques qui traitent les 
données. Bien au contraire, c'est l'ensemble du système d'informa- 
tion et son organisation qui sont l'objet de menaces. C'est l'informa- 
tion au sens large qui est concernée. En conséquence, les objectifs 
de sécurité devront être positionnés à ce niveau. 


2. Référentiels normatifs 
applicables 


Le système d'information est un sous-ensemble qui s'inscrit 
dans le champ plus vaste du système de management d'une 
organisation. 


Les normes ISO 9000 définissent, non seulement les spécificités 
liées à la qualité, mais surtout les exigences fondamentales pour 
établir, mettre en œuvre, exploiter, surveiller, réexaminer, tenir à 
jour et améliorer un Système de Management quel qu'il soit. 


De plus, pour assurer la sécurité des informations contenues 
dans les systèmes qui les traitent, les instances normatives inter- 
nationales ont rédigé la série des normes ISO 27000 (Techniques 
de sécurité - Système de gestion de la sécurité de l'information). 


3. Organisation des dossiers 


Pour tenir compte de la segmentation des approches normatives 
pratiquées par les experts internationaux, la présentation des dos- 
siers est la suivante : 

- le dossier [H 3 280] qui traite de la maîtrise des prestations de 
service Information Technology (ISO/CEI 20000). Ce dossier est 
orienté vers la production des services informatiques et est intitulé 
ITIL et ISO 20000 ; 

- un lot de trois dossiers orientés vers les études et réalisations 
informatiques : 


e processus d'ingénierie informatique [H 4 028v2], 
e produit logiciel [H 4 029], 
e gestion du cycle de vie du logiciel [H 4 031]. 


4. Instances (rappel) 


ISO (the International Organization for Standardization) est 
une fédération internationale des organismes nationaux de 
normalisation. 


Le travail de préparation des standards internationaux est nor- 
malement mené par les comités techniques ISO. Chaque orga- 
nisme, intéressé par un sujet pour lequel un comité technique a 
été établi, a le droit d'être représenté à ce comité. 


La Commission Électronique Internationale (CEI) s'occupe de 
tous les sujets qui concernent les standards électrotechniques. 


Les standards internationaux réalisés et adoptés par les comités 
techniques sont distribués aux membres pour le vote. La publi- 
cation en tant que standard international nécessite l'approbation 
d'au moins 75 % des membres participant au vote. 


L'Association française de normalisation (AFNOR) est le 
représentant de l'ISO en France. Elle a pour mission d'animer, 
de coordonner l'élaboration des normes et de promouvoir leur 
utilisation. 


Les normes internationales (standard), réalisées et adoptées par 
les comités techniques, sont distribués aux membres pour le vote. 
La publication en tant que standard international nécessite l’appro- 
bation d'au moins 75 % des membres participant au vote. 


5. Concepts (vocabulaire) 


Il faut faire une distinction entre les deux mots « information » et 
« donnée ». 


Le terme «information » vient du latin informare qui signifie 
mettre en forme. En fait, le même mot désigne à la fois le message 
(communication, média) et les symboles codés (signes, alphabet) 
qui sont contenus dans le message. 


Le terme « donnée » correspond à une représentation de l'infor- 
mation selon des règles codées. Les données sont conservées sur 
différents types de supports (papier, magnétique, numérique). 
Dans les systèmes de traitement de l'information, il existe deux 
composants : les données et les traitements. 


La définition de la norme ISO/CEI 27000 du danger est la 
suivante : c'est une substance, un objet, une situation où un 
phénomène pouvant être à l'origine d'un dommage ou d'un 
préjudice. 


Exemple : produit toxique, virus, inondation, incendie... 


La définition de la norme ISO/CEI 27001 de la sécurité de 
l'information est la suivante: c'est la protection de la 
confidentialité, de l'intégrité et de la disponibilité de l'informa- 
tion (cf. 8 11.3). 
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6. Série ISO/CEI 27000 


6.1 Structure normative 


Cette série de normes appartient à la catégorie des Technologies 
de l'information dans la partie Techniques de sécurité. Elle 
comporte les documents suivants : 


— ISO/CEI 27000 (publié en février 2011) - Systèmes de management 
de la sécurité de l'information — Vue d'ensemble et vocabulaire ; 

— ISO/CEI 27001 (publié en décembre 2007) - Systèmes de mana- 
gement de la sécurité de l'information - Exigences ; 

— ISO/CEI 27002 (publié en juin 2005) - Code de pratique pour la 
gestion de sécurité de l'information (ISO/CEI 17799 : 2005 et rectifi- 
catif 1 de 2007); 

— ISO/CEI 27003 (publié en février 2010) - Lignes directrices pour 
la mise en œuvre du système de management de la sécurité de 
l'information ; 

— ISO/CEI 27004 (publié en décembre 2009) - Management de la 
sécurité de l'information - Mesurage ; 

— ISO/CEI 27005 (publié en juin 2011) - Gestion des risques liés à 
la sécurité de l'information ; 

— ISO/CEI 27006 (publié en mars 2007 et projet de nouvelle 
norme en septembre 2011) - Exigences pour les organismes pro- 
cédant à l'audit et à la certification des systèmes de management 
de la sécurité de l'information ; 

— ISO/CEI 27011 (publié en décembre 2008) - Lignes directrices 
pour le management de la sécurité de l'information pour les orga- 
nismes de télécommunications sur la base de l'ISO/CEI 27002. 


7. Norme ISO 27001 


7.1 Contexte 


Un premier document ISO/CEI 17799 publié en 2005 traitait des 
techniques de sécurité - Code de bonne pratique pour la gestion 
de la sécurité de l'information. Ces recommandations de mise en 
œuvre sont reprises dans l'annexe 1 normative de l'ISO/CEI 27001. 


La norme ISO/CEI 27001 est une norme d'exigence. Elle sert de 
référentiel pour une certification d'un Système de Management de 
la Sécurité de l'Information (SMS). 


Cette norme est alignée sur les référentiels ISO 9001 (qualité) et 
ISO 14001 (environnement). Aussi, lorsque c’est opportun, il est 
recommandé de réaliser des économies d’échelles en procédant à 
une certification multinle. 


ÉTABLIR (P) 


Appréciation risque 


Plan traitement risque 


Acceptation risque 


EXIGENCES ATTENDUES 
SÉCURITÉ GÉRÉE 


L SURVEILLER (C) >; 
Revue des risques 


METTRE EN ŒUVRE (D) AMÉLIORER (A) ' 
! Plan traitement risque Amélioration risques ! 


Figure 1 - Cartographie des processus du SMSI 


Pour une certification, aucune exclusion n'est autorisée sur 
l'ensemble de ces paragraphes. 


7.3 SMSI 


Les articles du paragraphe N° 4 de la norme ISO/CEI 27001 dres- 
sent l'inventaire des exigences normatives à satisfaire pour une 
certification. On remarque que les processus exigés respectent le 
principe de l'amélioration continue. Ce principe repose sur le 
découpage en quatre quadrants (P.D.C.A.) d'un disque (appelé 
aussi roue de Deming dans le domaine de la qualité, à savoir : 

— P : établissement du SMSI (Plan) avec les processus d'appré- 
ciation des risques, d'élaboration du plan de traitement des 
risques et d'acceptation des risques ; 

-D: mise en œuvre et fonctionnement du SMSI (Do) avec le 
processus de gestion du plan de traitement des risques ; 

— C : surveillance et réexamen du SMSI (Check) avec le proces- 
sus de revue des risques ; 

— À : mise à jour et amélioration du SMSI (Act) avec amélioration 
du processus de gestion des risques en sécurité de l'information. 


La figure 1 résume graphiquement les processus du SMS. 


Monsieur William Edwards Deming (1900-1993) a été un 
chercheur en mathématiques au ministère américain de l'Agri- 


culture et un expert en échantillonnage au Bureau américain du 
recensement le nrix iananais de la Qualité norte anissi son nam 
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l'est courant d'utiliser divers logiciels aussi bien dans notre environnement 

professionnel que personnel. Bien souvent cette utilisation est soumise au 
respect de conditions plus ou moins restrictives qui figurent dans la licence. 
Les enjeux économiques sont considérables. Depuis les années 1980, le mou- 
vement prônant l'utilisation du logiciel libre change de plus en plus la donne. 


Dans un tel contexte en pleine évolution avec, d'une part, le mouvement des 
logiciels libres et, d'autre part, la multiplication des licences propres aux entre- 
prises éditrices, le choix d'une licence devient de plus en plus complexe et 
stratégique pour sa diffusion. Ce choix dépendra de la volonté de son auteur 
ou de son éditeur, titulaire des droits patrimoniaux. En ce qui concerne les 
logiciels libres, ils se caractérisent par une très grande permissivité dans leur 
utilisation et leur diffusion. Ils sont indissociables d'un projet qui porte généra- 
lement le même nom, qu'il y ait une seule personne pour le mener ou 
plusieurs équipes de développement, graphisme, marketing... 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie 
est strictement interdite. — © Editions T.I. H 9 002 - : 


115 


Référence Internet 


H9002 


LOGICIELS LIBRES 


1. Bref historique 
du mouvement libre 


Le mouvement en faveur du logiciel libre est né de la volonté de 
partage et de diffusion des connaissances qui anime la 
communauté scientifique. 


Au début des années 1980, l'expansion et la vulgarisation de 
l'informatique a fait naître un nouveau marché très rentable: 
l'édition de logiciels. Les éditeurs créent et vendent le produit sans 
communiquer le code source afin de se réserver le monopole 
d'exploitation et d'imposer de cette façon leurs conditions. 


En parallèle la communauté scientifique poursuivait ses 


recherches en donnant un accès libre au code source. 


Le code source est la version intelligible et compréhensible 
par un humain d'un programme informatique. Il est écrit dans 
un langage (ou plusieurs langages) dit « de programmation » 
qui décrit par des mots et formules le fonctionnement précis 
d'un logiciel. Ce code n’est pas directement intelligible par une 
machine. Il doit être traduit en code machine ou code 
exécutable. 


Dans ce contexte et en réponse au système propriétaire UNIX 
Richard Stallman, alors chercheur au Massachusetts Institute of 
Technology (MIT), démissionne et décide de se consacrer au projet 
GNU, à savoir l'écriture d'un système d'exploitation complet et 
libre. 


Afin de promouvoir GNU, Richard Stallman crée un an après, en 
1985, la Free Software Foundation (FSF). Ses premiers travaux ont 
alors consisté à définir le concept du logiciel libre en posant les 
fondations éthiques et juridiques via la licence GPL (la licence 
publique GNU, qui sera renommée plus tard « licence publique 
générale »). 


Le mouvement prend de l'ampleur au milieu des années 1990 
avec Linux, son fer de lance, puis avec le serveur web Apache 
(environ 70 % de parts de marché) et dans les années 2000 avec la 
suite Openoffice.org et le navigateur Internet Mozilla Firefox. 


Pour plus d'informations sur l'historique, le lecteur pourra 
consulter l’article « logiciels libres » de Philippe Aigrain qui, par 
ailleurs, rappelle les principales réalisations, les principaux pro- 
jets et met en avant les outils et services de développement 
(référence [1] de la fiche documentaire [Doc. H 9 002]) ainsi que 
les sites Internet http://www.fsf.org et http://www.gnu.org/ 
licenses/gpl-faq.fr.html 


2. Présentation des licences 
libres 


2.1 Qu'est-ce qu'une licence 


Une licence est un contrat dans lequel figure les conditions 
de garantie, d'utilisation, de modification, de copie, de 
distribution du logiciel. Elle confère des droits mais aussi des 
obligations aux utilisateurs et développeurs. 


Ces conditions peuvent être plus ou moins restrictives et 
doivent être conformes aux diverses législations. L'existence 
d'une licence est, bien sûr, conditionnée à la détention du droit 
d'auteur ou copyright par son auteur. 


Le copyright est une notion qui émane du droit anglo-saxon. Il 
ne recouvre que l'aspect patrimonial contrairement au droit 
d'auteur qui englobe le droit moral (l'œuvre est l'expression de la 
personne et le droit moral en garantit la protection en tant que 
telle). 


Cependant, depuis la convention de Berne, ces deux termes sont 
devenus synonymes. La protection d'une œuvre est automatique 
et ne requiert pour son existence aucune procédure de dépôt ou 
d'enregistrement. Cela bien sûr est vrai pour les pays signataires 
ou visés par ladite convention. 


Toutefois, l'existence d'un dépôt ou d'un enregistrement peut, 
en cas de contentieux, faciliter la preuve de la paternité de l'œuvre 
et la date de sa création. 


Deux catégories de licences coexistent: les licences dites 


« propriétaires » et les licences dites « libres ». 


2.2 Pourquoi une licence libre 


Les développeurs souhaitant rendre leur logiciel libre auraient 
pu se passer de l'étape « licence », la procédure étant de ne rien 
faire ; de fait leur logiciel relèverait du domaine public. N'importe 
qui pourrait l'utiliser, faire les modifications souhaitées. En effet, 
les logiciels relevant du domaine public sont, par définition, non 
soumis à une quelconque licence. Ils sont gratuits et libres de 
droit. 


En revanche, une fois modifiée, la nouvelle version d'un tel logi- 
ciel peut être placée sous une licence propriétaire ou libre et donc 
ne pas respecter la volonté de son auteur, d'où l'intérêt d’une 
licence qui fixe ce que l’auteur souhaite ou ne souhaite pas dans 
l'utilisation de son logiciel. 


Si le souhait de l’auteur du logiciel est de partager avec la 
communauté, il optera pour une licence libre dont le contenu sera 
fonction du niveau de liberté qu'il veut procurer. 


2.3 Qu'est-ce qu'un logiciel libre 


Traditionnellement, les logiciels commerciaux étaient distribués 
sous une licence propriétaire. 


Ce type de licence était, jusqu'au début des années 1990, choisi 
par les éditeurs de logiciels commerciaux. Ce choix correspondait, 
et correspond toujours, à une volonté de la part de l'éditeur de 
valoriser au maximum son droit de propriété intellectuelle sur le 
produit, afin de tirer des revenus directs de la concession de 
licences à des utilisateurs. 


Le copyright, où droit d'auteur, est ainsi assorti de clauses visant 
à restreindre les libertés octroyées à l'utilisateur (soumission à 
redevance, interdiction de copier, d'accéder au code source, de 
procéder à des modifications, de distribuer). Ce logiciel, distribué 
par l'éditeur sous forme de code exécutable (code objet) 
uniquement, ne permet donc pas au licencié (détenteur de la 
licence) d'accéder au code source du logiciel (ne lui permettant 
pas ainsi de corriger les bogues, d'extraire des composants du 
logiciel ni d'apporter des modifications pour l'adapter à ses 
besoins), à l'inverse des logiciels libres. 


Dans le cas des logiciels libres, le détenteur de la licence se voit 
remettre le (ou peut librement accéder au) code source du logiciel. 
Il jouit d'une grande liberté mais il a également des devoirs fixés 
par la licence. Et le non-respect des termes de la licence fait perdre 
à l'utilisateur l'intégralité des droits sur le logiciel. 


Deux organismes ont défini le logiciel libre. 


Selon la Free Software Foundation (FSF), un logiciel est libre s'il 
confère les quatre libertés suivantes à l'utilisateur : 


«La liberté d'exécuter le programme, pour tous les usages 
(liberté O). 
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« La liberté d'étudier le fonctionnement du programme, et de 
l'adapter à vos besoins (liberté 1). Pour ceci le code source est une 
condition requise. 


« La liberté de redistribuer des copies, donc d'aider votre voisin 
(liberté 2). 


« La liberté d'améliorer le programme et de publier vos amélio- 
rations, pour en faire profiter toute la communauté (liberté 3). Pour 
ceci l'accès au code source est une condition requise. » (D'après 
« Qu'est-ce qu'un logiciel libre ? » http:/www.gnu.org/philosophy/ 
free-sw.fr.html) 


Pour l'Open Source Initiative (OSl), un logiciel est libre si dix cri- 
tères sont satisfaits. Ces critères, plus techniques et pratiques que 
ceux de la FSF, permettent, eux aussi, de déterminer si un logiciel 
est libre ou propriétaire. Nous y trouvons notamment : 


-— l'intégralité du code source (critère 4) ; 

- la non-discrimination entre les personnes ou groupes (critère 
5); 

- la non-discrimination entre les domaines d'application (critère 
6) ; 

— la licence ne doit pas être spécifique à un produit (critère 8) ; 

- la licence ne doit pas contaminer d’autres logiciels (critère 9) ; 


Une description et une analyse de ces critères a été faite et est 
accessible sur le site http:/www.linux-france.org/article/these/osd/ 
fr-osd-1.html. 


À côté, nous avons les critères énoncés dans le cadre du projet 
Debian (qui met à disposition une distribution Linux, c'est-à-dire 
une méthode d'installation de celui-ci) ; ces critères sont matériali- 
sés, dans son contrat social, par Les principes du logiciel libre, 
également connus sous l'acronyme DFSG (pour Debian Free 
Software Guidelines). Cette définition est moins restrictive que 
celle issue de la FSF. Elle conçoit que des modifications apportées 
à un logiciel puissent ne pas être divulguées. 


La qualité de « logiciel libre » s'apprécie donc au regard de la 
licence conférée. Seule l'analyse du contenu de la licence permet 
de déterminer si un logiciel est libre ou non. Le logiciel libre est, 
avant tout, un logiciel protégé par le droit d'auteur, soumis à une 
licence, et régi par la législation du pays concerné. La licence n'a 
donc pas pour objet de transférer un droit de propriété, ni d'abou- 
tir à une renonciation au droit d'auteur ou de faire tomber le logi- 
ciel dans le domaine public. 


Les logiciels libres ne doivent pas être confondus avec les grati- 
ciels (en anglais freewares) qui sont des logiciels, certes, gratuits 
mais propriétaires. De plus, un logiciel libre n'est pas forcément 
aratuit llne enriété nent la raommerrialiser aver des cerviree [race 


2.4.1 Licences interdisant l'appropriation 
du logiciel 


Parmi ces licences figurent la plus célèbre des licences libres, la 
licence GPL (licence publique générale GNU - GNU General Public 
License). 


Il s'agit d'une des licences majeures du projet GNU (avec la 
LGPL que nous aborderons au paragraphe 2.5.1). 


B Les fondements principaux ont été écrits par Richard Stallman 
dans la version 1 de la GPL ; une version 2 (GPLv2) est née en 1992 
avec l'appui d'un juriste renommé, Eben Moglen, afin que celle-ci 
ne puisse être contestée juridiquement. 


La GPL intègre les quatre libertés fondamentales énoncées dans 
le paragraphe 2.3. Elle place automatiquement sous licence GPL 
les versions modifiées diffusées au public et élaborées à partir 
d'un programme sous licence GPL. C'est le copyleft ou « gauche 
d'auteur » qui l'oblige. Celui-ci détourne le principe du copyright 
pour garantir la liberté d'utilisation, d'étude, de modification et de 
diffusion du logiciel ainsi que de ses versions dérivées. 


M Face aux évolutions actuelles, Richard Stallman a lancé une 
consultation publique, avant l'adoption de la version 3 de la GPL, 
laquelle se veut plus représentative des souhaits et des problémati- 
ques de la communauté libre via une approche plus démocratique. 
Tout le monde a été invité à émettre ses commentaires concernant 
le projet de la GPLV3 sur le site de la Free Software Foundation. 


Cette nouvelle version veut également être une réponse aux 
incertitudes légales liées à la diversité des législations. 


GPLv3 http://gplv3.fsf.org 


La Free Software Foundation a publié une première trame de la 
version 3 de la GPL qui a suscité pas mal de débats et controverses 
(définis ci-après) afin d'aboutir à la version finale publiée le 29 juin 
2007. 

Les principales différences entre la version 2 et la version 3 
concernent : 

—la gestion numérique des droits (DRM) : la GPLv3 l'interdit 
alors que la GPLV2 ne prévoit aucune disposition à ce sujet ; 

— la problématique du brevet : présente dans la version 3 de la 
GPL ; 

—la compatibilité avec d'autres licences : la GPLv2 ne prévoit 
aucune disposition tandis que le projet de la GPLV3 affirme sa 
compatibilité sous certaines conditions. 


Les questions de la DRM et les brevets logiciels (face à la 
pratique réelle et actuelle de brevetabilité des logiciels) ont suscité 
des controverses et divisent actuellement la communauté. 
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# informatique est devenue d'un usage courant dans la vie quotidienne des 
entreprises et dans le secteur public. Elle n'en revêt pas moins des spécifici- 

tés qui obligent toujours à de constantes adaptations du droit et par-là même, 
des obligations contractuelles qui en découlent. Parmi les premières, on peut 
citer la profonde modification de la loi informatique, fichiers et libertés [1] ainsi 
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que la refonte du Code des marchés publics. Parmi les secondes, on peut noter 
un mouvement en faveur de l'infogérance (avec mise en place des centres de 
secours, d'hébergement et d'exploitation) et de la tierce maintenance applica- 
tive (TMA). 


De son côté, la jurisprudence joue un rôle non moins négligeable qui est de 
mettre en place un certain nombre d'éléments régulateurs, conçus comme des 
obligations à la charge des parties parmi lesquelles la collaboration, l'informa- 
tion, le conseil et la mise en garde. Ces éléments régulateurs interviennent tant 
avant qu'après la conclusion du contrat. 


C'est pourquoi, quelle que soit leur importance, les obligations des parties 
relatives à la réalisation d’un projet informatique doivent être appréhendées dès 
la période précontractuelle. Cette dernière génère, en effet, des liens de droit qui 
engagent les parties bien avant la signature du contrat lui-même. 


En outre, compte tenu de la caractéristique technique de la matière, les 
contrats informatiques présentent des particularités qui se sont traduites, en 
droit, par l'adaptation de certaines règles applicables notamment à la définition 
des besoins, à la maîtrise d'œuvre, à la garantie des vices cachés et à la non-con- 
formité, ou encore à la subtile distinction entre obligation de résultat et 
obligation de moyens et au renforcement de garanties (robustesse, pérennité, 
maintenabilité, traçabilité, évolutivité...). 


En quelques pages, il ne s'agit nullement de faire une étude de chaque contrat 
propre à l'informatique, si tant est qu'une telle étude puisse être faite, étant 
donné la diversité des montages contractuels possibles et la difficulté d'élaborer 
des contrats types. 


La présente étude aborde le contrat informatique à travers, d'une pari, les obli- 
gations communes à toutes situations et, d'autre part, les deux formes de 
contrats les plus usitées actuellement, que sont le contrat d'intégration de sys- 
tème et le contrat d'infogérance avec les garanties de secours, plus communé- 
ment appelé « facilities management ». 


Pour de plus amples renseignements concernant les divers contrats en infor- 
matique, le lecteur se reportera à la référence [2]. 


A H A services télématiques qu'il désire qu'en cours d'utilisation en affi- 
1 ÿ Obl igations pre nant le système de mois en mois, est partiellement responsable des 
et postcontractuelles imperfections du système [4]. 


Le client qui n’est pas susceptible de pouvoir procéder lui-même 
à l'appréciation de ses besoins peut recourir à un conseil extérieur. 


1.1 Définition des besoins M Le cahier des charges est l'expression formalisée des besoins du 
client, des objectifs, des contraintes et des priorités que l'informati- 


:  : | | . sation de l'entreprise doit prendre en compte. 
En phase précontractuelle, il existe à la charge du client un devoir 


d'exprimer, de communiquer, voire de préciser, au fournisseur les 


besoins à satisfaire. En contrepartie, ce dernier doit fournir des L'Afnor définit le cahier des charges en matière de logiciel 
conseils ainsi qu'une information loyale. comme un « document établi par le demandeur définissant les 

clauses techniques, les clauses de qualité et les clauses adminis- 
B Pour ce faire, le client doit analyser et exprimer ses besoins. En tratives applicables à la fourniture recherchée ; il sert de base à 
effet, pour que le fournisseur puisse proposer à l'utilisateur la solu- la proposition du fournisseur, et pourra faire l’objet d’un 
tion informatique la plus apte à satisfaire ses besoins, il est néces- contrat » (norme Z61-102). 


saire qu'il puisse les connaître et les comprendre ; c'est pourquoi il 
revient au client de procéder à l'analyse et à l'expression desdits 
besoins afin de pouvoir les communiquer à son fournisseur. 


Le cahier des charges, au sens administratif, comporte tous 
les documents, généraux ou particuliers, qui fixent les condi- 
tions dans lesquelles les marchés sont exécutés [5]. 

La jurisprudence rappelle régulièrement que l'entreprise qui sou- 
haïte s'informatiser doit définir ses besoins réels et les objectifs à 


atteindre en précisant clairement la nature et l'importance des tra- Bien que non obligatoire, c'est un document fondamental. En cas 
vaux qu'elle souhaite voir réaliser [3]. La Cour de cassation a notam- de litige, il peut, en effet, servir de moyen de preuve de la demande 
ment considéré que le client qui ne définit pas le contenu des du client [6]. 


Toute reproduction sans autorisation du Centre français d'exploitation du droit de copie est strictement interdite. 
H 4 128 -2 © Techniques de l'Ingénieur 


120 


Référence Internet 


H4128 


LES CONTRATS EN INFORMATIQUE 


Cependant, le fournisseur ne peut pas toujours se retrancher der- 
rière l'absence de cahier des charges. Sur le fournisseur pèse une 
obligation de conseil que la jurisprudence ne manque pas de rappe- 
ler. En effet, le professionnel peut difficilement se cacher derrière 
une attitude passive du client, surtout en l'absence de tout conseil 
spécialisé. 


B Le professionnel a l'obligation de fournir au client une documen- 
tation commerciale claire respectant la réglementation en vigueur, 
et notamment l'emploi de la langue française, ainsi que l'interdic- 
tion de la publicité mensongère. 


Le langage de l'informatique comporte un vocabulaire particulier 
faisant référence à des concepts spécifiques sur lesquels l'accord ne 
se fait pas toujours unanimement. En effet, certains termes techni- 
ques n'ont pas toujours le même sens chez tel ou tel fournisseur et, 
à plus forte raison, pour l'utilisateur. 


Le recours aux expressions ou termes étrangers est prohibé, s'il 
ne s'accompagne pas d’une traduction française lorsqu'il existe une 
expression ou un terme publié dans le cadre de la loi sur 
l'enrichissement de la langue française. Il en est ainsi, notamment, 
des termes bogue (bug), logiciel (software), système d'exploitation 
(operating system) ou encore secours informatique (back up) [7]. 
Toutefois, le texte peut être complété d'une ou plusieurs traductions 
en langue étrangère. 


En outre, la loi impose l'emploi de la langue française dans la 
désignation, l'offre, la présentation, le mode d'emploi ou d'utilisa- 
tion, la description de l'étendue et des conditions de garantie, des 
produits et services informatiques ainsi que dans les factures y affé- 
rentes [8]. 


Les documents en anglais accompagnant des progiciels n'ont 
toutefois pas besoin d'être traduits en français dès lors qu'ils sont 
destinés à un installateur spécialisé [9]. 


Enfin, la documentation commerciale ne doit pas inclure d'infor- 
mations fausses ou mensongères, destinées à tromper le client sur 
les fonctionnalités et les capacités d'un matériel ou d'un progiciel 
[10]. 


B Durant la phase de négociation, les pourparlers peuvent contenir 
des promesses qui deviennent alors des engagements. 


Juridiquement, on parle souvent du « contrat de promesse » qui 
est une promesse unilatérale car il n'engage qu'une seule partie au 
contrat définitif. Cependant, dès qu'une promesse unilatérale réunit 
toutes les conditions légales [11], elle est valable et constitue la loi 
des parties au sens de l’article 1134 du Code civil qui dispose que 
« les conventions légalement formées tiennent lieu de loi à ceux qui 
les ont faites ». 

Nota : aux termes de l’article 1108 du Code civil, quatre conditions sont essentielles pour 
la validité d’un contrat : le consentement de la partie qui s'oblige, sa capacité de contracter, 
un objet certain qui forme la matière de l'engagement, une cause licite dans l'engagement. 

Par ailleurs, le fournisseur s'engage à ne pas retirer son offre pen- 
dant la durée de validité de celle-ci. Dans certains cas, la rupture 
abusive de pourparlers peut être retenue. 


1.2 Éléments « régulateurs » 
de la relation pré- et postcontractuelle 


La jurisprudence a mis en place un certain nombre d'éléments 
régulateurs tenant compte de la différence de compétence entre les 
parties. Conçus comme des obligations à la charge des parties, ils 
interviennent tant avant qu'après la signature du contrat. 


B |! pèse sur le fournisseur une obligation de conseil. Le devoir de 
conseil comprend deux niveaux : 


— la délivrance de conseils pour que le produit vendu ou le ser- 
vice fourni réponde aux attentes du client ; 
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— la mise en garde qui oblige le professionnel à anticiper les dan- 
gers potentiels que peut courir le client en utilisant le produit ou le 
service. 


Le niveau qui doit être respecté par le vendeur ou le prestataire 
dépend de la combinaison de deux paramètres : 


— plus le client est néophyte, plus le niveau d'information doit 
être complet ; 

— plus le produit ou le service est dangereux, plus le niveau 
d'information doit être complet, étant précisé que la notion de 
danger ne se réduit pas aux risques d'atteinte à l'intégrité physique 
[12]. 


L'obligation est d'autant plus forte que le client est particulière- 
ment démuni et qu'il peut légitimement ignorer certaines arcanes 
de l'informatique (8 1.3) ou ne pas comprendre certains éléments de 
documentation qui lui sont fournis, ou encore ne pas percevoir 
l'opportunité de communiquer au fournisseur telle ou telle informa- 
tion. 


B Le client a une obligation de collaboration. Le fournisseur d’un 
système ou de prestations informatiques ne peut assumer ses obli- 
gations que si son client collabore, c'est-à-dire lui communique tous 
les renseignements utiles à la mise au point du système et des logi- 
ciels (éléments et paramètres, contraintes spécifiques...) et participe 
au suivi de l'exécution du contrat [13]. 


Par exemple, un client qui ne s'est pas suffisamment impliqué 
dans la recherche d'une solution tendant à limiter les inévitables dif- 
ficultés pouvant exister au démarrage ne peut obtenir la résiliation 
du contrat aux torts du fournisseur [14]. 


Exemple : la Cour de cassation a considéré qu'un client avait man- 
qué à son obligation de collaboration, en ne répondant pas aux sollicita- 
tions insistantes de son fournisseur lui demandant de valider les 
applications logicielles concernant deux des produits qu'il a élaborés 
M5]. 


La collaboration est une obligation réciproque, également à la 
charge du fournisseur. 


1.3 Appréciation des compétences 
informatiques du client 


Le contenu des obligations réciproques des parties dépend du 
degré de compétence du client en matière informatique. 


M Degré de compétence du client : l'obligation de conseil à la 
charge du fournisseur, telle que dégagée par la jurisprudence, est 
variable suivant le degré de compétence du client en matière infor- 
matique. Ainsi, plus le client est compétent, plus l'obligation de 
conseil pesant normalement sur le fournisseur est atténuée. En 
revanche, l'obligation du vendeur professionnel est renforcée en 
présence d'un acheteur profane. 


M Intervention d'un conseil extérieur : le caractère professionnel du 
client s'apprécie non seulement au regard de ses compétences 
intrinsèques mais également à l'égard de conseils extérieurs pou- 
vant intervenir à ses côtés, en particulier au moment de la définition 
des besoins (8 1.1). 


Certes, le recours au conseil extérieur n'est pas une véritable 
obligation. Cependant, en ne recourant pas à cette aide extérieure, 
le client méconnaît son obligation de se renseigner, même si dans 
le même temps le fournisseur peut méconnaître son devoir de 
conseil. 


Lorsque le client a effectivement recouru aux services d'un 
conseil spécialisé et que survient un échec, les obligations de 
conseil et de mise en garde du fournisseur peuvent s'en trouver 
atténuées. En effet, l'obligation du spécialiste se trouve fondamen- 
talement allégée si, soit sur sa suggestion, soit sur une démarche 
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autonome du client, le client a été assisté par un conseil extérieur 
pour la définition de ses besoins, voire ultérieurement pour le 
suivi d'exécution du contrat. 


En cas d'échec, il appartient au client de vérifier que le conseil 
extérieur a été diligent au regard des relations contractuelles 
(contrat de conseil ou d'assistance à maîtrise d'ouvrage). 


1.4 Portée des obligations en termes 
d'obligation de résultat 
ou d'obligation de moyens 


Tout professionnel a le devoir d'agir en vertu des règles de l'art de 
son métier, c'est-à-dire toutes les connaissances reconnues par ses 
pairs. Cependant, en cas d'échec, sa responsabilité dépend du type 
d'obligation conclue : obligation de moyens, obligation de résultat. 


M Les obligations de moyens et de résultat s’appréhendent par le 
biais de la charge de la preuve : 


— lorsqu'une prestation fait l'objet d'une obligation de résultat, le 
prestataire est présumé responsable de son échec ; il peut s’exo- 
nérer de sa responsabilité en prouvant que l'inexécution provient 
d'une cause étrangère qui ne peut lui être imputée (cas de force 
majeure, faute du client ou fait d'un tiers) ; 

— lorsqu'un prestataire fait l'objet d'une obligation de moyens, 
c'est au client d'apporter la preuve que le prestataire a commis une 
faute. 


B Critères d'appréciation de l'obligation principale du contrat: la 
jurisprudence apprécie les obligations au cas par cas. Par exemple, 
dans les contrats de maintenance, l'obligation est plutôt de moyens 
dans la mesure où le bon fonctionnement des matériels dépend à la 
fois des interventions techniques du prestataire et du comportement 
de l'utilisateur. Par exemple, le prestataire informatique qui fournit 
un système de transmission numérique doit être considéré comme 
étant soumis à une obligation de moyens, dès lors que le contenu de 
son obligation est aléatoire, en raison du caractère innovant du pro- 
cédé et de la complexité technique à le mettre au point. Contribuent 
également à la qualification d'obligation de moyens, la spécialisa- 
tion du client dans le domaine des réseaux et sa maîtrise de l'état de 
la technique qui sont entrés dans le champ contractuel entre les 
deux professionnels [16]. 


En revanche, dans les contrats clés en mains, il s'agit d’une obli- 
gation de résultat, dans la mesure où le professionnel s'engage sur 
une prestation complète dont il prend en charge l'ensemble des 
aspects, V compris la maîtrise d'œuvre, c'est-à-dire la direction, le 


À chacun de ces objets s'applique un type de contrat avec des 
droits et obligations spécifiques (vente, location, licence...). Pour 
une étude de ces différents contrats en informatique, on se reportera 
à la référence [17]. 


BH Contrats de vente ou de location de matériel : les contrats de 
matériel prennent la forme de contrats de vente, de location ou de 
vente éventuellement par crédit-bail. 


La vente est un contrat soumis à un ensemble de règles générales 
issues du Code civil [18]. La location est un contrat soumis à des 
règles spécifiques [19]. Le crédit-bail s'appuie à la fois sur une vente 
entre un fournisseur et un crédit-bailleur et sur une location avec 
option d'achat entre un crédit-bailleur et un utilisateur. Il est régi par 
une loi spécifique [20]. 


B Contrats de licences d'utilisation de progiciel : les contrats de 
licence de progiciel sont une catégorie de contrat par lequel le four- 
nisseur accorde un droit d'utilisation du progiciel au client. Ce droit 
est normalement restreint à un droit d'utilisation qui interdit notam- 
ment toute modification du progiciel ; le fournisseur ne communi- 
que d’ailleurs pas au client les éléments correspondants (source, 
documentation de réalisation, etc.). 


B Développement ou réalisation de logiciels spécifiques : les contrats 
de développement de logiciels sont une variété de contrat d'entreprise 
par lequel le fournisseur s'engage à réaliser un logiciel spécifique pour 
un client. Il appartient à la catégorie des contrats de louage d'ouvrage. 


Le contrat de louage d'ouvrage est celui « par lequel l’une des 
parties s'engage à faire quelque chose pour l’autre moyennant 
un prix convenu par elles » [21]. 


Il met en relation le client (utilisateur) et le fournisseur (entrepre- 
neur). Pour le fournisseur, les obligations sont d'exécuter l'ouvrage 
conformément à la définition des besoins, à l'état de l’art et aux 
engagements contractuels (performances, ergonomie...). Pour le 
client, les obligations sont d'effectuer la réception de l'ouvrage et de 
payer le prix convenu. 


En matière informatique, l'obligation de délivrance étant constatée 
par la recette du logiciel, un soin particulier doit être donné à l'orga- 
nisation et à la réalisation de cette étape contractuelle capitale. 


B Maintenance informatique : 


En matière informatique, la maintenance est définie comme 
«un ensemble d'actions tendant à prévenir ou à corriger les 
dégradations d’un matériel afin de maintenir ou de rétablir sa 
conformité aux spécifications » [22]. 


La suite de cet article ne fait pas partie de l'extrait en consultation gratuite. 


Si vous souhaitez accéder au contenu intégral de cette base documentaire, rendez-vous 


à la fin de ce document. 


Et pour toute question sur nos offres d'abonnement, n'hésitez pas à contacter le service 
Relation clientèle au 01 53 35 20 20 ou par email à l'adresse infos.clients@teching.com. 
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‘écrivain, essayiste et humoriste américain Mark Twain, issu d’une famille 

de pionniers qui avait connu l'expansion de la colonisation et le dépla- 
cement vers l’ouest de la nouvelle frontière, fut à son époque un contempteur 
des excès de la vie américaine et le dénonciateur de ses débordements. Dans 
une formule imagée, il avait coutume de dire : « Je n'ai rien contre le progrès, 
c'est le changement qui me dérange ». 


Cette formule pose, avec humour, le véritable débat concernant l'impact sur 
notre société des technologies du numérique et de l'Internet, comme notre capa- 
cité à accepter les transformations qu'elles génèrent dans notre environnement, 
tant privé, que professionnel, sous l'angle des comportements, des pratiques, 
des manière de faire et d’être. Partie intégrante de notre environnement, elles 
transforment de façon accrue notre environnement quotidien, ainsi que nos 
conditions de travail. Elles posent la question de notre capacité à appréhender 
les changements majeurs qui nous attendent. 


L'une des questions les plus sensibles concerne la définition des compétences 
susceptibles de permettre l’acculturation aux nouvelles technologies et, partant, la 
transformation de notre environnement économique et social. Ces technologies 
ont en effet de particulier que, pour bénéficier de leur plein effet, il paraît néces- 
saire de changer de façon radicale nos façons d'échanger, de collaborer, comme 
de manager. 
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Dès lors se pose la question essentielle de notre capacité à définir la nature 
des nouvelles compétences, de façon à rendre compte des problématiques 
aussi différentes que la formalisation des formations qui préparent à ces nou- 


veaux métiers, 


l'évolution et l'actualisation des référentiels métiers des 


entreprises, et surtout, de façon plus générale, la clarification du spectre de ces 


technologies sous l'angle de leur réalité profonde. 


1. Quelques chiffres 
en France « numérique » 


En dépit du discours récurrent des médias, la France est entrée 
de façon insensible dans une économie post-industrielle dans 
laquelle la part des technologies du numérique et de l'Internet joue 
un rôle important. Dans le même temps, la société française a évo- 
lué, sans pour autant qu'elle en ait forcément conscience. 


Le 11 février 2009, Microsoft (voir Nota) publiait les résultats 
d'une importante enquête intitulée « Référence des usages des 
technologies de l'information au travail en France ». L'étude dresse 
notamment la cartographie des usages professionnels dans les 
entreprises. Elle permet surtout de comprendre, de manière assez 
explicite, la réalité actuelle. 


Nota : l'étude, initiée et coordonnée par Microsoft, a été publiée en 2009, dans le 
cadre de son Centre des usages. Elle associe les travaux de quatre cabinets spécialisés : 

— Eranos pour la cartographie des usages et technologies en entreprise ; 

- Added Value pour l'enrichissement de la cartographie précitée par le biais de 
focus-groups ; 

— Ifop pour la pondération des éléments par le biais d'un échantillon de 1 011 utilisa- 
teurs en entreprise ; 


— Bearing Point pour une analyse plus approfondie des axes de conduite du 
changement dans trois grandes entreprises françaises. 


B En premier lieu, il ressort que 12 millions de personnes travaillent 
tous les jours sur un ordinateur en France, ce qui représente 46 % 
de la population active de notre pays. Autre chiffre instructif, 61 % 
des ordinateurs sont désormais dans les foyers, marquant le pas 
décisif de l’informatisation de notre société dès lors que - désor- 
mais - la majorité du parc d'ordinateurs se trouve chez les particu- 
liers, et non plus dans les entreprises. Ce chiffre, symptomatique en 
lui-même, semblait inaccessible il y a à peine 10 ans. 


Surtout, ce document de travail éclaire la réalité quotidienne de 
l’utilisation informatique. Un collaborateur, dans l'Hexagone, 
passe 4 h 30 par jour sur son ordinateur, à rapprocher d'une durée 
du travail quotidienne moyenne de 7 h 30 (tableau 1). 


B En complément de ce constat, le rapport publié par l'Institut 
Montaigne (voir Nota) à l'été 2011, intitulé Le défi numérique : 
Comment renforcer la compétitivité de la France, met l'accent sur 
les trois axes prioritaires du numérique dans notre pays : 


—les systèmes d'information, considérés comme des vecteurs 
de la performance ; 

-— l'appropriation du numérique par la société dans son 
ensemble, facteur clé du développement des usages ; 

— la gouvernance du numérique et de l'Internet, de façon plus 
globale. 


Nota : laboratoire d'idées créé en 2000 par Claude Bébéar, l'Institut Montaigne est un 
think tank constitué dans une vocation d'analyse, de comparaison et de proposition, en vue 
de contribuer au développement des atouts de la France dans le contexte mondial. Il ras- 
semble des chefs d'entreprise, des hauts fonctionnaires, des universitaires et des 
représentants de la société civile. Le groupe de travail en charge du rapport était Michel 
Volle. 


Il ressort de la lecture de ce document que notre pays, 
5° économie du monde par le PIB, est la 20° nation pour le numé- 
rique. Bien plus, il accuse une perte de 5 places entre 2009 et 2010. 
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Tableau 1 - Quelques chiffres 
de la France « numérique » 


Sources lfop Domaines er Temps 
et Microsoft 2009 d'activité Activités (en min) 
Mettre à jour 
: 47 
des données 
Travailler sur Rechercher 36 
: . De Créer 29 
Durée quotidienne 
de travail : 7 h 30 Analyser 27 
Dont durée de tra- Coopérer 19 
vail sur un 
ordinateur : 4h30 | Communiquer : | Informer 40 
1h20 
Partager 37 
Gérer son S'organiser 18 
temps : 1/2h 
Synchroniser 14 


Tableau 2 - Filière Internet et ventes électroniques 


en France 
2010 2015 (prévisions) 
Filière Internet 6 " 
française (part du PIB) 37% 5,5 % 
Montant 70 milliards € 129 milliards € 
Ventes électroniques 13 % du chiffre 20 % du chiffre 
(sociétés françaises) d'affaires d'affaires 
(21 % en 
Grande-Bretagne) 


B Pour ce qui concerne l'équipement des ménages en matière 
d'ordinateurs et d'accès Internet, la France figure au 20° rang des 
pays européens. Sa pratique de l'Internet en matière de 
communication, d'acquisition des biens et des services, de 
recherche d'emploi ou de formation, se situe dans la moyenne 
européenne. Enfin, si 51 % des entreprises françaises ont un site 
Web, ce chiffre se révèle inférieur à la moyenne européenne qui 
est de 64 %. 


Il est par ailleurs significatif de constater l'évolution de la 
filière Internet et des ventes électroniques en France 
(tableau 2) pendant la période 2010-2015. Les chiffres font 
cependant apparaître qu'en 2010, le chiffre d'affaires réalisé en 
France, en matières de ventes électroniques, est inférieur d’un 
tiers à celui effectué par la Grande-Bretagne pour le même 
exercice. 
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B En complément des chiffres précités, une estimation — dressée 
en 2009 - établissait que la filière du numérique et de l'Internet 
était à l'origine de la création de 700 000 emplois directs depuis 
15 ans, en France, sur un ensemble de 1 150 000 emplois directs 
ou indirects. 


Pour conclure cette rapide évaluation chiffrée - non exhaustive — 
il est aussi possible de préciser que : 


—96% des sociétés d'au moins 10 salariés sont connectées à 
l'Internet ; 

— 54 % des sociétés françaises de 10 salariés ou plus, disposent 
d'un site Web (contre 64 % en moyenne européenne) ; 

—77 % des entreprises ayant accès à l'Internet utilisent les Admi- 
nistrations dans leurs relations avec les Autorités publiques ; 

— 33% de l'ensemble des entreprises françaises disposent d'un 
extranet ; 

— 42 % d'entre elles, d'un intranet. 


2. Enjeux actuels 
des compétences 


La forte propagation des technologies du numérique et de 
l'Internet, en France, s'est manifestée par une évolution en trois 
phases distinctes. 


B Années 1990/2000 


Elles ont été celles de l'émergence d'Internet, avec l'intégration à 
notre environnement de l'infrastructure et des fondations de cette 
technologie. Cette première époque n'a pas suscité de transfor- 
mation notable, en raison de son caractère invisible et souterrain, 
néanmoins indispensable. 


B Années 2000/2010 


Plus récentes, elles ont été celles de l'implémentation technolo- 
gique, autrement dit de la mise en place des superstructures qui se 
sont traduites notamment par, d'une part l'expansion considérable 
des sites (Internet-intranet-extranet) avec la formalisation de 
l'entreprise étendue, d'autre part l'augmentation des fonctionnali- 
tés proposées par ces dispositifs sociotechniques (voir Nota). De la 
sphère informationnelle à l'origine, ils ont gagné par la suite l'envi- 
ronnement collaboratif et autorisé la productivité qui en découle. 


Nota : terme de sociologie appréhendant la technologie dans sa dimension systém- 
tique, à la fois technique (outils), et sociale (usages). 


B Années 2010/2020 
Déjà en marche. Elles seront de facon vraisemblable celles de 


3. Autour de la notion 
de compétence 


B Guy Le Boterf [1], dans son ouvrage Repenser la compétence, 
dont la nouvelle édition a paru en 2010, suggère quinze propo- 
sitions concrètes. || invite, dans la première d'entre elles, à traiter 
la compétence comme un processus, et non plus comme une 
somme de ressources. Il met aussi l'accent sur le fait que le mana- 
gement des hommes n'est pas la simple addition des savoirs, 
savoir-faire et savoir-être, qui constitue le triptyque de base des 
compétences. Il s'accompagne aussi de la nécessité de formaliser 
et de construire le transfert des compétences comme un processus 
de transformation. 


Surtout, l'ensemble de cette démarche s'inscrit dans une pers- 
pective d'employabilité qui dépasse largement, par son impact, la 
notion plus restrictive du seul emploi. 


B Dans un ouvrage antérieur Construire les compétences indivi- 
duelles et collectives, ainsi que dans ses autres écrits [2] [3], Le 
Boterf rappelle que la compétence se manifeste dans l’action. « La 
compétence est la mobilisation ou l'activation de plusieurs savoirs, 
dans une situation et un contexte donnés ». Elle fait donc appel à 
des ressources cognitives. 


L'auteur met par ailleurs en avant la nécessité pour tout profession- 
nel de construire et de développer des « schèmes ». Ces derniers sont 
la combinaison dynamique des ressources mobilisées dans des situa- 
tions précises. Ils associent connaissances, savoir-faire, culture, res- 
sources émotionnelles, savoirs formalisés et réseaux d'expertise. 
Guy Le Boterf recense plusieurs types de compétences : 


— les savoirs théoriques (savoir comprendre, savoir interpréter) ; 

— les savoirs procéduraux (savoir comment procéder) ; 

— les savoir-faire procéduraux (savoir procéder, savoir opérer) ; 

— les savoir-faire expérientiels (savoir y faire, savoir se conduire) ; 

— les savoir-faire sociaux (savoir se comporter, savoir se conduire) ; 

— les savoir-faire cognitifs (savoir traiter de l'information, savoir 
raisonner, savoir nommer ce que l’on fait, savoir apprendre). 


B Le terme de compétence dans le domaine des ressources humai- 
nes apparaît aux USA dans un article publié par Craig C. Lundberg [4] 
dès 1972. Il est formalisé en 1973 par David McClelland [5] qui distin- 
gue la connaissance (compréhension et maîtrise théorique ou prati- 
que d'un sujet), l'aptitude (capacité à obtenir un résultat prédéterminé 
dans une économie de moyen) et les attitudes (qui conjuguent 
affects, comportements et connaissances). 


B L'analyse effectuée par Katz [6] en 1974, dans la lignée des tra- 
vaux de ces précurseurs, opère une distinction entre trois types de 
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